[IPython-user] Problem doing svn co behind proxy

David Cournapeau david@ar.media.kyoto-u.ac...
Sat Aug 18 04:45:24 CDT 2007


Stefan van der Walt wrote:
> On Mon, Aug 13, 2007 at 03:59:31AM -0600, Fernando Perez wrote:
>> I'm inclined to go with hg because:
>>
>> - As Ville mentioned, at least on the net there seems to be a lot of
>> evidence of the speed difference between hg and bzr being huge.
>
> I don't really mind which way this goes, but for a fair evaluation one
> should keep in mind that bzr was first developed to be
> feature-complete; only then did they have a performance drive (from
> version 0.10 up).  The current version is much zippier than its
> predecessors.  The following link is already outdated, but it gives
> you some idea of the improvements they've made:
>
> http://bazaar-vcs.org/Performance/0.15
>
> Also, make sure you use the 'python-celementtree' package
> (vs. 'python-elementtree', implemented in pure Python).
Since enthought already uses hg, I would say that it is a pretty big 
argument againt bzr and for hg. But for the fun:

totally unscientific benchmark of bzr for numpy and scipy
=========================================================

I did the following: I have imported numpy and scipy trees subversion 
trees into bzr, and made some timings (timings assume the tree is in os 
cache: eg I do the operation once, and then average on three runs). I 
put the operations I consider the most important (at least when I myself 
use bzr):

- branching numpy: ~ 26 seconds
- status at root of numpy tree: ~ 0.7 seconds
- getting the whole log (eg the ~ 3700 revisions of main trunk in one 
file): 0.9 seconds
- blaming one file: ~1 seconds (I guess this depends heavily on the file 
and its history, so I took multiarray.c, a file which is likely to get a 
lot of history and commiters).
- committing: ~1.5 seconds.
- merging a few files: ~2 seconds.

Except maybe status, all those are much faster than svn because of 
network, so I don't see how bzr's speed could be an issue (and also, 
note that because it is imported from svn, it has some overhead for 
commit, because the way I set up my thing). So I would say that at least 
for trees of the size of numpy, bzr is definitely usable (and scipy is 
not fundamentally different, except for branching and merging, where it 
is ~1.5 slower, and commit which is twice slower).

Also, importing numpy and scipy trees (all revisions: trunk, tags and 
branches; the branch relationship is lost, though, I think) is a one 
command in bzr.

David


More information about the IPython-user mailing list