FW: Re: yet another dvcs shootout (this time python-devel)

[Arne Bab.]

Von: "Christian Boos" <cboos at neuf.fr>
> Arne Bab. wrote:
> > $ time bzr branch http://code.python.org/python/3.0
> > ...
> > Branched 37407 revision(s).
...
> > $ time hg clone http://code.python.org/hg/branches/py3k/
> > ...
> > added 2532 changesets

> Looks like the two branches don't mirror the same thing (or don't have
> the same revision "depth" for the same thing).

Good spotting, I didn't see that.

Could it also be the way the repositories were converted, or how the changesets get stored?

I'm just repeating the test with the provided Python 2.x repos to see if they behave differently from the 3.x ones.


$ time bzr branch http://code.python.org/python/trunk
No handlers could be found for logger "bzr"
[13868] 2008-11-05 11:36:44.358 INFO: Branched 40626 revision(s).
Branched 40626 revision(s).

real 24m0.446s
user 12m47.623s
sys 0m15.842s


$ time hg clone http://code.python.org/hg/trunk/ python-hg-trunk
requesting all changes
adding changesets
adding manifests
adding file changes
added 40556 changesets with 86253 changes to 8166 files
updating working directory
3922 files updated, 0 files merged, 0 files removed, 0 files unresolved

real 2m40.237s
user 1m34.721s
sys 0m13.027s


So it seems that the py3k hg repo history might be incomplete but that the 2.x repos are the same.

With these repos containing the same changesets (roughly, since bzr tracks dir name changes) Mercurial is about 9 times faster than Bazaar.

>>> (24.0 + 0.44 / 60 ) / ( 2 + 40.237 / 60 )
8.989434400294563

And hg only uses about half as much space as bzr for the repository data (with bzr 1.5 that is - that was the stable version in my Gentoo tree as of 2008-10-31):

$ du -hs python-bzr-trunk/.bzr python-hg-trunk/.hg
214M python-bzr-trunk/.bzr
111M python-hg-trunk/.hg


Also a full bzr log takes about 2.5 times as long as a full hg log in the cloned python 2.x repositories (so hg log is about 2.5 times faster than bzr log):

$ time bzr log
...
real 1m10.258s
user 0m37.236s
sys 0m2.250s

$ time hg log
...
real 0m27.886s
user 0m12.737s
sys 0m0.482s

>>> (1 + 10.258/60) / (27.886 / 60)
2.519472136555978

As I understand it, the new revlog in C should give Mercurial another nice speedup here (am I right in that?).


A local clone in Mercurial is about 11 times faster than a local clone in bzr.

$ time bzr branch python-bzr-trunk/ python-bzr-trunk2
...
real 11m36.265s
user 8m38.400s
sys 0m11.145s


$ time hg clone python-hg-trunk python-hg-trunk2
...
real 0m59.759s
user 0m23.321s
sys 0m5.455s


A second run (backwards, with hot filesystem caches) gave even stronger results:
$ rm -r clone python-hg-trunk
$ time hg clone python-hg-trunk2 python-hg-trunk
real 0m38.779s
user 0m23.394s
sys 0m4.635s

With bzr I first cloned backwards to heat up the filesystem caches and then cloned again:
$ rm -r python-bzr-trunk
$ bzr branch python-bzr-trunk2 python-bzr-trunk
$ rm -r python-bzr-trunk2
$ time bzr branch python-bzr-trunk python-bzr-trunk2
...
real 12m8.374s
user 8m44.747s
sys 0m10.782s

Result: bzr is unusable for quick local clones of not-so-small projects.


Sidenote:
$ #cold copy of .hg
$ time cp -r python-hg-trunk/.hg tmp-hg
real 0m53.981s
user 0m0.077s
sys 0m3.486s

# hot copy of .bzr
$ time cp -r python-bzr-trunk/.bzr tmp-bzr
real 0m25.738s
user 0m0.012s
sys 0m1.368s

# hot copy of .hg
$ rm -r tmp-hg
$ time cp -r python-hg-trunk/.hg tmp-hg
real 0m14.702s
user 0m0.085s
sys 0m6.241s


To alleviate some doubts about system load: this is what top gave while I did the first local clone of the bzr repo:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
23202 arne 21 1 359m 255m 3412 R 70.1 12.7 1:39.33 bzr

CPU load due to bzr moved between 60% and 80% while cloning.

The general load on the system while running bzr commands was about the same as while running hg commands (I compiled stuff with niceness 11 = low priority).


So Mercurial is far faster than bzr, while being a lot more newbie friendly than git (especially when the newbies are former svn users - Python currently uses svn).


Best wishes,
Arne
-- 
unpolitisch sein
heißt politisch sein,
ohne es zu merken.
- Arne
_______________________________________________________________________
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1758 bytes
Desc: S/MIME Cryptographic Signature
Url : http://selenic.com/pipermail/mercurial/attachments/20081105/918a4498/attachment.bin