[Numpy-discussion] Moving away from svn ?

[David Cournapeau]

On Jan 5, 2008 12:22 AM, Stefan van der Walt <stefan at sun.ac.za> wrote:
> Hi David
>
> On Fri, Jan 04, 2008 at 08:24:04PM +0900, David Cournapeau wrote:
> >     First things first, happy new year to all !
>
> Happy new year!  It's been great so far :)
>
> >     Having recently felt the pain to use subversion merge, I was
> > wondering about people's feeling on moving away from subversion and
> > using a better system, ala mercurial or bzr (I will talk about bzr
> > because that's the one I know the most, but this discussion is really
> > about using something better than subversion, not that much about bzr).
> > I think this could be an important step forward, and is somewhat related
> > to the discusions on scikits and co.
>
> I have a couple of questions, that you may be able to answer more
> quickly than what I could, googling for a few hours:
>
> 1) Is it easy to setup bzr so that many people have submit-access to
> the main-branch, i.e. so that we don't need a central "patch-manager"?
If you read the linus' email I linked, he says a word about that, as
well as several related problems (having several "main branches", and
problems related to access/regression testing/build bot). I don't know
much about it, but bzr's team uses a software which tracks merge
requests. The trunk is thus read only (in the sense that nobody pushes
change to it), and pull changes from the software tracking merge
requests.

https://launchpad.net/pqm

My understanding, but I have never used that feature, is that
mercurial has something similar.

>
> 2) With a DRCS, we have to check out the whole repository, instead of
> the current sources only.  Currently, the history amounts to roughly
> 70Mb, but that includes files that have been deleted etc.  Is there
> any way to compact the repository, or to say "let's only go 100
> revisions back, and for the rest query the main branch"?  I'm just
> worried that, some day in the future, a user will need to do an
> extremely large checkout to hack on a fairly small codebase.

Git has this feature, bzr not yet. I don't know about mercurial. In
itself, it is not so much a problem because the amount of data is not
so big compared to a svn checkout. As I mentionned previously, for
scikits and scipy import, the whole history imported un bzr is smaller
than a svn checkout ! It depends a lot on the codebase details, but
again, my understanding is that the repository formats used by DVCS
makes it quite efficient to get the whole history.

This is the reason why I linked the Keith Richard blog: in his
discussion about why repository format matters, there is the story of
the 2.7 Gb mozilla CVS repository going to 8.2 Gb when imported in
svn, going back to 450 Mb when imported with git (compared to a 350 Mb
checkout !).
>
> 3) Which of bzr, mercurial and git has the best merging capabilities?
> I heard a while back that git does not try to be too clever about it,
> while the others do -- I wonder how that worked out.

I don't know. Mercurial historically used an external merge tool, I
think. I can just say that most of the time, bzr merge works without
any problem, whereas svn never works. I basically gave up on using
merge with svn: for my scons related work, I just checked out from
svn, created a bzr repository from it, and made my changes inside bzr,
because I was fed up with svnmerge failing every single time I wanted
to pull merges from other branches. Maybe I am too stupide, but I
don't see how anyone would want to use the merge command from svn.

cheers,

David