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

Rich Felker dalias
Sun Dec 25 20:55:15 CET 2005


On Sun, Dec 25, 2005 at 01:04:16PM +0100, Luca Barbato wrote:
> 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

Deps for client, or server? I think these deps for svn are incorrect
anyway (some of them are only needed for broken db-based backend which
is deprecated by text).

Personally I've never had a use for Python and hardly ever had a use
for Perl, and don't think it's reasonable to require such bloat on the
client's end. On the server it really makes no difference.

Rich





More information about the ffmpeg-devel mailing list