[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Switching to Subversion

From: Thomas Arendsen Hein
Subject: Re: Switching to Subversion
Date: Mon, 13 Nov 2006 12:20:24 +0100
User-agent: mutt-ng/devel-r804 (Linux)

* Miles Bader <address@hidden> [20061113 10:41]:
> Sascha Wilde <address@hidden> writes:
> > I have to plug mercurial[0] in this thread.  It's a distributed SCM
> > written in python, which has a ui which is very similar to cvs, too
> > (at least for all operation where this is possible).  
> Here's Keith Packard's (of X11 fame) rather well-argued take on the
> issue:
>    http://keithp.com/blog/Repository_Formats_Matter.html
> He provides pretty good arguments _against_ subversion, but also
> addresses mercurial vs. git a bit (mercurial is in some sense a riff on
> git, btw).

If I interpret "riff" as "rip off", I have to disagree here.

Citing a presentation of the original author of Mercurial:
(the Ottawa Linux Symposium slides on
|   Early History Of Mercurial
| April 6, 2005:
|   Bitmover announces end of gratis version of Bitkeeper
|   Linus mentions he's looking at alternatives
|   I start working on Mercurial
|   Linus starts working on Git
| April 8:
|   Linus releases initial nearly useless Git snapshot
| April 19:
|   Mercurial 0.1 released
|   features: familiar interface, efficient storage,
|   commit/checkout/clone/pull/merge
| April 20:
|   Linus fails to destroy Git in a timely fashion

> Here's the final few paragraphs:
>    I know Git suffers from its association with the wild and wooly kernel
>    developers, but they've pushed this tool to the limits and it continues
>    to shine. Right now, there's nothing even close in performance,
>    reliability and functionality.

Mercurial comes close in some aspects and is faster in others. In
fact git is much slower and consumes huge amounts of disk space if
you don't regularly do git-pack-objects. Which Mercurial such
cleanup work isn't needed.

And the blog says that the repository format of git is much more
stable, because it saves one file for each object while Mercurial
appends to file logs and truncates to the last file log size when a
commit or pull gets interrupted. But he doesn't mention that when
you start packing objects you'll move around all your history and in
case of trouble you'll have trouble with exactly this history.
I'm not saying that git will kill your data, but I'm saying that I
consider this at least as dangerous to your data as a simple
truncate (which only is done while a write lock is held).


Email: address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]