[Numpy-discussion] Moving away from svn ?
Charles R Harris
Fri Jan 4 15:36:21 CST 2008
On Jan 4, 2008 2:05 PM, David Cournapeau <firstname.lastname@example.org> wrote:
> On Jan 5, 2008 5:36 AM, Charles R Harris <email@example.com>
> > A quick google for benchmarks show that a year ago, hg was a bit faster
> > generated smaller repositories than bzr, but I don't think the
> difference is
> > enough to matter.
> Forget a year ago, because as far as bzr is concerned, they got much
> faster (several times faster for common operations like
Sure, that's why I mentioned the time. Bzr used to claim better directory
renames than hg, but that is not the case since version 9.4. So on and so
forth. They are both moving targets.
bzr is not tied to linux.
It is, in that development is funded by Canonical, but I haven't used either
on windows, so don't have any idea how they compare in that regard.
They always have win32 binaries, TortoiseBzr
> has a longer history than the mercurial one, and as said previously,
> one developer of bzr at least is mainly a windows user. I don't want
> to sound like I defend bzr, because honestly, I don't care about which
> one is used, but so far, the arguments I heard against bzr do not
> reflect my experience at all.
> One thing that bzr tries hard is the general UI, and the explicit
> support for several workflows (with moderately advanced concepts such
> as shared repositories, bound branches: for example, with a branch A
> bound to branch B, a commit is first pushed on branch B, and if
> successfull, applied to A; for centralized worflows, this makes things
Hg has always recommended a similar process: clone the repository, push your
changes to the clone, fix what needs fixing, and commit. It's not an atomic
operation, though. I don't know where things are in that regard at the
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion