Emacs repository benchmark: bzr and git

[Stefan Monnier]

Stefan> Actually, this last point is the same as the second.  As for the
Stefan> remaining three they come in this order:

Stefan> * bzr st <single file> needs to be instantaneous.
Stefan> * bzr diff -r <something> needs to take at most a couple of seconds
Stefan> * bzr log needs to be much faster for single files[1] and for
Stefan> subsets of history.

Stefan> The first is very serious since it make vc-bzr
Stefan> unusable.

Actually, I've just installed a patch in Emacs's trunk to make vc-bzr.el
parse the dirstate file more completely, so `bzr status' is not needed
nearly as often.  But I don't have any documentation about the dirstate
format, so it's not very satisfactory.

Anybody knows where I can find some doc about that file's format?

> Can you tell us which precise information is needed by vc-bzr (my
> understanding, dating from vc-cvs years ago now, is that it wants
> to display the file version in the mode line).

It wants to know if the file is under Bzr's control, whether it's
added/removed/edited/uptodate and what is the current revision number
(basically).  Ideally also if there are conflicts (tho it currently
doesn't use `bzr status' for that but just looks for the .MINE and
friends instead).

> I suspect that 'bzr st' aim does not fit vc-bzr needs at all
> (even if it's the closest available command from bzr).

It seems to fit just fine, except it takes an insance amount of time to
give me the list of pending merges.  2 problems with that:
1 - performance
2 - the list includes merges that are not pertinent (because that merge
    does not affect the specified file(s)).
Admittedly, the worst part

Stefan> Also, given the current performance problems, we
Stefan> haven't tried much more.  E.g. I have no idea how
Stefan> easy it will be to keep Bzr-Emacs in sync with Gnus's
Stefan> repository.

> Does that mean that Gnus is maintained as a separate project and
> regularly kept in sync/imported in the emacs CVS repository ?

Yes, the two branches are sync'd both ways (I believe they both
currently use CVS as the main repository and the sync'ing is done
semi-automatically via Arch).

> If yes, the best solution will be what bzr call 'nested trees'
> which is currently working on.

I'm not sure this will be sufficient: the Gnus files are not all neatly
confined within a single directory.  Arch handles such cases just fine
(patches to Emacs files that aren't in Gnus are just ignored and the
rename support is sufficiently good to be able to figure out which
files correspond to which between the two projects; better yet, the two
projects were brought together after the fact and the renames are
properly handled even without a common ancestor thanks to the use of
arch-tags in the files).

> I think you both agree :) Internally bzr tends (this is less and
> less true) to process the whole tree and then filter the results.

Could be.  I hope not: the lessons learned from Arch should include
avoiding to touch/construct/look-at files unless absolutely necessary.
But I'm sure it's not the only problem: the speed difference between
"bzr tags" and "bzr tags --show-ids" can't be due to
whole-tree operations.


        Stefan