[Numpy-discussion] Moving away from svn ?
Fri Jan 4 15:35:29 CST 2008
On Jan 5, 2008 6:17 AM, Ondrej Certik <firstname.lastname@example.org> wrote:
> On Jan 4, 2008 10:05 PM, David Cournapeau <email@example.com> wrote:
> > On Jan 5, 2008 5:36 AM, Charles R Harris <firstname.lastname@example.org> wrote:
> > >
> > >
> > > A quick google for benchmarks show that a year ago, hg was a bit faster and
> > > 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
> > commit/branch/log/merge).
> > > but Linus was definitely focused on speed, which is easy to understand if
> > > you look at the churn in the kernel. Anyway, I suspect that, technically,
> > > both bzr and hg are suitable choices. I'm not sure esr correct that it is
> > > unlikely that both are going to last long term, bazaar (the ancestor of bzr)
> > > is used for Ubuntu. But the two are similar and fill the same niche, so I
> > > expect that one or the other will become dominant in the wild. And hg seems
> > > to have the advantage of a head start and not being as tightly tied to
> > > Linux.
> > bzr is not tied to linux. 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
> > easier). I honestly do not know if this is significant. bzr claims its
> > merge capability is better: I do not know if this is true, or if that
> > matters at all.
> > I would rather discuss those than "bzr is tied to linux", because I
> > don't think they are based on accurate or recent informations. As I
> > said, I have bzr imports of scipy and scikits, and I could easily to
> > the same for hg, make them available for everybody to play with.
> Instead of devising our own arguments, read this:
> and the mercurial response therein.
I personally do not find those pages (both mercurial and bzr) really
informative. Bzr page sounds too much like advertisement, and the
answer from mercurial's team, logically, sounds like an agressive
> Numpy-discussion mailing list
More information about the Numpy-discussion