Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?

[Rob Landley]

On Saturday 09 February 2008 10:49:49 Johannes Schindelin wrote:
> Hi,
>
> On Sat, 9 Feb 2008, Felipe Contreras wrote:
> > Right now I can't use qemu because a bug introduced in the last months
> > and with git-bisect I probably would be able to fix it myself.
>
> Just clone git://repo.or.cz/qemu.git, then.

I've been using git://git.kernel.dk/data/git/qemu.git although I personally 
prefer mercurial.  (It's easier to learn and to use, you get the web viewer 
for free, etc.)

The thing is, git and mercurial are roughly equivalent, they're both 
distributed source control systems and you can losslessly convert from one to 
the other and back again, because they have all the same metadata.  (See 
http://kernel.org/hg/linux-2.6 as an example of a mercurial mirror of a git 
repository.)

But the difference between centralized source control and distributed source 
control is huge.  The distributed ones store more information.  This means 
you can convert losslessly convert from svn->hg, but if you convert from 
hg->svn you lose information.  (So if you convert from hg->svn and then back 
from svn->hg, you have a different mercurial repository, and pulling from the 
original would be a bad idea because it would think it had lots of duplicate 
changes.)

And of course CVS isn't even a full fledged centralized repository, it's an 
ancient holdover from the 1980's that doesn't even have the concept 
of "changesets".  (In cvs, changes are tracked in individual files.  Changes 
that touch multiple files at the same time have to be collated after the fact 
by comparing timestamps and hoping the descriptions match up.  This is a 
brittle heuristic at best; CVS hasn't got this _concept_.  Doing a binary 
search for the change that introduced a bug is amazingly painful with CVS, 
and even proposing tracking renames violates the design assumptions.  Even 
patch knows how to touch more than one file at a time; CVS does not.)

It is possible to use a distributed source control system as if it were a 
centralized source control system.  Just accept all changes as patches, never 
pulling directly from any other trees.  And thus you can hold off on learning 
new distributed source control concepts indefinitely.

> Hth,
> Dscho

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.