calling for dirstate dogfooders, and change in branch policy now all tests pass

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> DIRSTATE STATUS
> ---------------
> 
> The dirstate branch now has the dirstate based tree format as the
> default. Its passing all tests, so I think at this point we should
> change the policy to 'please run all tests before committing' to prevent
> regressions.
> 
> It badly needs dogfooding though - I've started dogfooding it, and will
> continue to do so. its about 50% faster for status now, and there is
> room to move. I intend to do the _iter_changes API alterations I
> discussed with Aaron tomorrow, and hopefully Martin will be able to get
> the nested reference trees merged shortly too. That will cause a one-way
> upgrade of your repository though, so, be careful if you do dogfood -
> i.e. be sure to use a scratch branch & repository, or just dont run 'bzr
> upgrade'.

Just to be clear, right now we don't require updating your branch and
repo, but the official dirstate format will change when Martin merges
the new stuff, so that we can support nested trees. And that will
require an upgrade. It also sounds like it will be an incompatible bump
to the WorkingTree format (no upgrade from dirstate now to
dirstate-with-trees). Which will mean that when it is merged you'll need
to probably 'bzr remove-tree; <pull bzr-dirstate>; bzr checkout'.

...

>  - Figure out the regression on xml based trees (???) (I am guessing its
> a hashcache usage issue - should be simple)

I've done profiling, and I'm pretty convinced this is not genuine. When
I did a 'bzr --lsprof status' I had a difference of about 40ms out of 1s
but bzr.dev was actually the slower one.

Running 'timeit bzr status' on the launchpad tree I have 1.93s with
bzr.dev, and 1.97s with dirstate. 40ms is well within the noise margin.
Or at least not worth spending a lot of time yet.  (running it again I
got 1.87s for dirstate)

>  - Remove the use of a regular hashcache completely, which will reduce
> parse time further still for dirstate tree operations. (???)
> 

I'll see about taking up hashcache operations. I also know that my
bisect code is imperfect at the moment (it doesn't take into account the
new sorting rules). So I'll probably fix that up first, and then go into
the hash cache stuff.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF5uz3JdeBCYSNAAMRArJ4AJ9s1j9RwUXLhv6ZO01ZNWjYMt/6VgCfeoMK
ZUiX6KJPA2A//K2d3pP9rwI=
=mjjh
-----END PGP SIGNATURE-----