Re: Switching to Subversion

[Thomas Arendsen Hein <thomas@intevation.de>]

* Miles Bader <miles@gnu.org> [20061113 10:41]:
> Sascha Wilde <wilde@sha-bang.de> 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
 http://www.selenic.com/mercurial/wiki/index.cgi/Presentations)
|   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).

Thomas

-- 
Email: thomas@intevation.de
http://intevation.de/~thomas/