Emacs repository benchmark: bzr and git
Vincent Ladeuil
v.ladeuil+lp at free.fr
Thu Mar 27 13:59:49 GMT 2008
>>>>> "Stefan" == Stefan Monnier <monnier at iro.umontreal.ca> writes:
>> I've tried to get a list of things that Bazaar needs to improve from
>> trawling through this list and bugs on the Bazaar tracker.
>> So far I have:
>> * bzr log needs to be much faster for single files[1] and for
>> subsets of history.
>> * bzr diff -r <something> needs to take at most a couple of seconds
>> * bzr st <single file> needs to be instantaneous.
>> * Must be able to get the diff between the current branch and its
>> parent very quickly.
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.
I know that one since it's the precise reason why I stopped using
vc-bzr months ago.
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).
I suspect that 'bzr st' aim does not fit vc-bzr needs at all
(even if it's the closest available command from bzr).
Stefan> Also it's very easy to fix by providing a new option
Stefan> that prevents outputting the list of pending changes
Stefan> (which is the operation that takes a long time, and
Stefan> we don't need that info anyway).
Correct. But with a better understanding of the needs we may find
a better solution without special-casing bzr st.
<snip/>
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 ?
If yes, the best solution will be what bzr call 'nested trees'
which is currently working on.
>> [1] Bazaar tends to assume you want to work with the whole
>> tree for every operation. I think this might be the root
>> cause of a lot of the disappointment in Bazaar's
>> performance.
Stefan> Actually, as far as I can tell, most of the above
Stefan> problems are unrelated to "single file vs whole
Stefan> tree": it takes about the same time to do it on a
Stefan> single file than on the whole tree.
I think you both agree :) Internally bzr tends (this is less and
less true) to process the whole tree and then filter the results.
Vincent
More information about the bazaar
mailing list