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
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
