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

[Michael Niedermayer]

Hi

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:
[...]
> Other questions?

it would be interresting to see some examples of the practical use cases
something like the equivalents of:

vi blah ; cvs di -u blah ; cvs commit blah
cvs up blah
cvs di -u -r 1.11 -r 1.12 blah
cvs log blah
cvs annotate -r 1.234 blah
cvs add blah
cvs remove blah
ssh server ; cp blah,v blue,v
cvs admin -o
cvs admin -m

and how much diskspace it needs on the client side

[...]
-- 
Michael