[Numpy-discussion] Moving away from svn ?
Fri Jan 4 10:56:49 CST 2008
On Jan 5, 2008 1:30 AM, Charles R Harris <firstname.lastname@example.org> wrote:
> I like Mercurial and use it a lot, but I'm not convinced we have enough
> developers and code to justify the pain of changing the VCS at this time.
I don't understand the number of developers argument: on most of the
projects I am working on, I am the only developer, and I much prefer
bzr to svn, although for reasons which are not really relevant to a
project like numpy/scipy.
> SVN g!enerally works well and has good support on Windows through tortoise.
That's where I don't agree: I don't think svn works really well. As
long as you use it as an history backup, it works ok, but that's it.
The non functional merge makes branching almost useless, reverting
back in time is extremely cumbersome,
> Mercurial also has tortoise support these days, but I haven't ever used it
> and can't comment on it. In fact, I've never even used Mercurial on windows,
> perhaps someone can relate their experiences with it. I suppose a shift
> might be justified if there is a lot of branch merging and such in our
> future. Anyone know what folks are working in branches?
Well, I started this discussion because of the scikits discussion. A
typical use of branches is for sandboxes: it makes a lot of sense to
use branches instead of sandboxes. Also, when branching actually
works, you really start using many branches: I do it all the time on
all my projects, and I am the only developer on most of them. It means
that you commit smaller changes (because comitting does not mean
makeing your changes available to the trunk), and instead of
submitting one big changeset, you actually submit a serie of small
changes. This really makes a big difference IMHO. Also, things like
log, blame are actually usable, since they are much faster on DVCS.
For something like scipy (less for numpy), where many people develop
different things, I think it really makes a lot of sense to use a
DVCS. I actually think scipy to be more distributed in nature than
many open source projects (again, this is much less true for numpy,
More information about the Numpy-discussion