Why git or Mercurial? (Was: Re: [Ffmpeg-devel] Switch to svn?)

Sun Dec 25 13:04:16 CET 2005

Rich Felker wrote:
> On Sun, Dec 25, 2005 at 07:20:31AM +0100, Luca Barbato wrote:
> 
>>Points:
>>1 - take less to deploy / don't require neon and happy friends
>>2 - has already a nice set of tools / yes are new and already have some
>>3 - allows the distributed model / not a big selling point given the 
>>audience ^^;
> 
> 
> This is hardly a detailed explanation. In the past, we have had
> in-depth discussions of different version control systems and their
> pros and cons. You shoud look these up in the archives and evaluate
> GIT and Mercurial in light of these.
> 
> Particular concerns:
> - anything that requires repo users to have a full copy of the repo
> (rather than just their checked-out version) is out of the question
> imo. it's a huge obstacle to people joining.
> - something with nasty dependencies (strange libs, strange lang
> (including c++), etc.) is undesirable.
> - ability to represent history of the tree and not just files, i.e.
> moving files etc.
> - ... lots of other stuff i don't remember or know about.
> 
> This is a complicated issue. If you want to promote something new when
> svn is already known to work well enough you need to be providing us
> damn good info to base decisions on..

git has those terrible deps:
:: openssl zlib perl python rcs

cogito may add in the mix
:: curl and rsync

mercurial has those terrible deps:
:: python and asciidoc xmlto for the documentation

subversion has those terrible deps:
:: apr-util optionally apache, every language known, neon, db4

Depending on your tastes about source or prebuilt:

- svn takes lots of time to build

- svn may be distributed with lots of deps

- the default git and mercurial implementation use python and/or perl 
for some or all tasks so it takes the time to have those built or, if 
you already have them, it takes just the time to fetch and unpack them.