Emacs repository benchmark: bzr and git

[Vincent Ladeuil]

>>>>> "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