emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Bazaar repository


From: John Arbash Meinel
Subject: Re: Emacs Bazaar repository
Date: Fri, 14 Mar 2008 08:23:29 +0000
User-agent: Thunderbird 2.0.0.12 (X11/20080227)

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

Eli Zaretskii wrote:
>> From: Matthieu Moy <address@hidden>
>> Date: Fri, 14 Mar 2008 10:58:13 +0100
>> Cc: Andreas Schwab <address@hidden>, address@hidden,
>>      address@hidden
>>
>>> Andreas Schwab <address@hidden> writes:
>>>
>>>> My first impression is that bzr is slow, so slow that it is completely
>>>> unusable.  How can it come that a simple bzr log takes more than a
>>>> minute to even start?  Even cvs log is instantaneous in comparison,
>>>> although it has to request the log from the server.
>> [...]
>> As opposed to that, bzr has to get a global view of history at least
>> to get the revision numbers (there was some plans caching this
>> information, I don't know what's the status).
>>
>> That said, the time for bzr log to start should clearly not be _that_
>> long.
> 
> Incidentally, why are we concentrating on "bzr log"? is that a
> frequent operation?  With CVS, I find myself doing "cvs log" only once
> in a few months, when I'm looking for a change corresponding to some
> ChangeLog entry.
> 
> Aren't "push" and "pull" much more important, as far as speed is
> concerned, for everyday work?  Also the equivalent of "cvs diff", I
> think.  Those are the ops I use much more frequently than "log" and
> "annotate".

I think it is because 'bzr log' is surprisingly slow when compared to
other systems, while the other commands are not.

The biggest reason 'bzr log' is slow is because we spend some time
analyzing the ancestry to give a "pretty" view, while git/hg do not.
Specifically, when you do "bzr log" we traverse the ancestry to figure
out when revisions were merged, etc.

I believe plain "git log" just starts outputting the revisions as it
encounters them, and "hg log" also outputs them as they are stored. In
the case of "hg" that means that the order of operations you did to
create the branch will change the order you see them displayed. So if
you and someone else do 2 commits and then you merge them, and they pull
you. At that point "hg log" gives different results, even though both
branches are "the same".

For example:

hg init A
cd A
echo foo > foo
hg add
hg commit -m 'init'
cd ..
hg clone A B
cd A
echo "A1" >> foo
hg commit -m "A1"
echo "A2" >> foo
hg commit -m "A2"
cd ../B
echo "B1" > bar
hg add
hg commit -m "B1"
echo "B2" >> bar
hg commit -m "B2"
hg pull ../A
hg merge
hg commit -m "Merged"
cd ../A
hg pull -u ../B

At that point doing:
cd A
hg log

gives me: (paraphrased for clarity)
changeset:   5:04157da570b3
summary:     Merged

changeset:   4:e44ea38fbbb9
summary:     B2

changeset:   3:d2df37f438ac
summary:     B1

changeset:   2:111f2448422b
summary:     A2

changeset:   1:3a8ecee8c0bf
summary:     A1

changeset:   0:5a118c651080
summary:     init

versus
cd B
hg log
changeset:   5:04157da570b3
summary:     Merged

changeset:   4:111f2448422b
summary:     A2

changeset:   3:3a8ecee8c0bf
summary:     A1

changeset:   2:e44ea38fbbb9
summary:     B2

changeset:   1:d2df37f438ac
summary:     B1

changeset:   0:5a118c651080
summary:     init


The other thing is that these numbers are going to be permanently
different for the two branches. Which means that you can't refer to
"revno 4 in branch A". Because someone with an effective clone of your
"branch A" might have different revisions.

We are working hard to decrease the cost of this ancestry lookup. We
have a couple plans which will allow us to determine the revision
numbers without having to look at all of history. We'll still look at
more than 0 history, but if we can bound the amount of history we have
to look at, it should help.


(I believe 'git log' defaults to showing the log based on a local sort
by date. Neither one tries to figure out that A1 and A2 were merged into
tip, which is another step that 'bzr log' does.)

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

iD8DBQFH2jYBJdeBCYSNAAMRAh/KAJ9pK07hLXcDBZY+GqZUYWaemSXTTQCdE1U6
hO2ad7jQ6e4h+jqIgNsOYgM=
=CX95
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]