yet another dvcs shootout (this time python-devel)

[Robert Collins]

On Wed, 2008-11-05 at 23:04 +0000, Paul Moore wrote:
> 2008/11/5 Robert Collins <robertc at robertcollins.net>:
> > Shared repositories have nothing to do with initial clone speed.
> 
> Hmm, and yet the recommendation for the Python repo is to download a
> tarball of a shared repo, then pull into that. I assumed that was
> intended to be faster than a simple bzr branch from the main repo.

That sounds like an accomodation to our network performance which has
(bluntly) sucked in the past. We have made significant improvements, and
are continuing to do so - but I suspect a tarball of any VCS's project
metadata will always be faster than unpacking and processing it
dynamically :).

> > As a Bazaar developer, I totally support you organising your repositories
> > as and how you desire.
> 
> Fair enough, and my apologies for putting words into your mouth. But
> nevertheless, whenever I've said that I have a Bazaar branch and bzr
> branch to create a second branch from it is annoyingly slow (and hence
> limits my ability to branch freely) the suggestions have always been
> to use a shared repo - which adds an extra directory level that I
> don't want. It seems to be the standard answer to "bzr branch is slow"
> comments. Which in turn gives the impression that standalone branches
> are to an extent second-class citizens (at least in terms of
> performance focus).

So shared repositories are our mechanism for reusing history across
branches; when you 'bzr branch localA localB' without a shared repo we
copy (with full traversal of history etc) the history database. This is
slower than just hardlinking the history files together like hg does and
even slower than just adding a new reference like git does. Running
multiple heads in a single branch is totally possible (the loom plugin
does this). We don't depend on hardlinking for a few reasons; primarily
it's not reliably portable (windows under some situations can hardlink,
FAT can't, MacOSX has a single dir tracking all hardlinks and
performance scales badly (though there is a newer fs type that fixes
this)) and as such we wanted a portable reliable answer for getting
really fast new branches. Secondly, when we copy data we prune out dead
heads in the history graph - a new clone has only the referenced data -
and hardlinking does not do that. Finally when we are copying data we
want to users to be totally confident its all intact, and simply
hardlinking would fail to expose any issues introduced into the
repository (e.g. by damaged disk sectors). 

> > Slow initial clone speed is a serious problem  - one
> > we've done a lot of work on, with both a similar feature to hg's history
> > punching (but more similar to git's alternates), and direct performance
> > work. I just tried the bzr component of the above comparison with bzr's
> > 1.8 release (about 5 months newer than 1.5):
> > Branched 37403
> > revision(s).
> >
> > real    4m26.156s
> > user    3m56.170s
> > sys     0m11.020s
> 
> That's a huge difference, and certainly emphasizes the importance of
> not basing my opinions on older versions. I will see if I can try a
> newer version of Bazaar (although I'd be much happier to do so if a
> simple "unzip and go" Windows binary was available).

We might want to hop off the hg list at this point :P - I try to be
discussing hg itself when posting here, so I don't wear out my
welcome :).

http://bazaar-vcs.org/Download has the generic download instructions.
https://edge.launchpad.net/bzr/+download has the windows binary
installers. The 1.9 series is having a few quirks (we're automating the
process) - but AIUI the 1.8 series is very reliable.

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20081106/6306b50c/attachment-0001.asc>