[Spam] Re: [CMake] Re: Migration to subversion

[Gonzalo Garramuño]

Alan W. Irwin wrote:
> developers, but most software projects (such as CMake) will never have more
> than a handful of active developers

cmake already has about 10-20 or so developers (if you consider all the 
.cmake module contributions).  People with commit access, however, are 
much fewer right now.

> 
> I assume that does not rule out git or Mercurial.  For example, from the
> git-svn crash course at http://git.or.cz/course/svn.html, it appears that
> git has the capability to use a centralized repository (the so-called bare
> repository), and I presume that is the case for Mercurial as well.

Not really. Both git and Mercurial are always distributed.  You can have 
one "official" repository but you cannot prevent people from cloning it.

> However, I admit to having no development experience with git or Mercurial.
> Is there anything compelling (e.g., fewer bugs, better documentation, more
> useful features aside from distributed?) about either over svn for 
> projects like CMake that use a centralized repo?
> 

See Linus presentation at google (available on youtube).  But basically, 
with git you get:

* Faster and smaller repositories.  A git repository will often be 1/3rd 
of an equivalent cvs or svn one.
* git guarantees that what you put in the repository is what you get 
out.  All commits are SHA1 verified.  CVS and SVN have no verification. 
  If disk corruption happens or a malicious user fakes a file or screws 
up, say, the ,v files, you can get garbage out without anyone noticing.
* git offers two apis (one for high level user access and one for low 
level admin/script access similar to using tricks in cvs like hacking 
the ,v files).
* Branches and merging are native to the repository.  Both can be done 
in linear time (and probably) with much less chance of conflicts.
* Distributed.  You can work with the repository without being connected 
(on a plane or laptop, for example) and then merge later.
* Distributed allows you to much more easily mix and match from several 
repositories of trusted persons, to create your own flavor of code.  For 
example, Linus is not an expert in networking, but he can easily fetch 
and merge network changes from other developers that are, once they 
verified the code (thus, reducing the amount of work *he* has to do on 
things he is not really an expert on).  A central repository makes it 
much more easy for the changes of the two developers to overlap or screw 
up the build of the other person while developing.  Or the developer 
just has to "never commit, until all your tests pass and your changes 
are done".
* git offers bisect options in linear time.  It becomes trivial to find 
a line commit that screwed up something.  There's nothing like that on 
CVS or SVN, where it has to be done manually.  And even then, it is not 
linear.
* git patches can be created to be easy to email for those that have no 
write access.
* git has proven scalability (for both git and the kernel, probably some 
of the largest per day/month commit base of any known projects).

With Mercurial you get the same except faster and smaller and only a 
single api.  It is at least 40% slower than git in my (short) 
experience.  Monotone offers better verification but much, much slower 
performance.

In summary, once you use git, if you are like me, you'll realize that 
you've been doing source version control wrong all these years *sigh*.

-- 
Gonzalo Garramuño
ggarra at advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy