[CMake] Re: Migration to subversion

[E. Wing]

On 12/22/07, Brandon Van Every <bvanevery at gmail.com> wrote:
> On Dec 22, 2007 6:48 PM, Andreas Schneider <mail at cynapses.org> wrote:
> > Rodolfo Schulz de Lima wrote:
> > > That's great news. Since I've never been involved in a CVS -> SVN
> > > migration, I couldn't help so much with it. Also, excuse me for assuming
> > > you weren't using svn and trying to sell it to you :)
> >
> > Before you switch to svn please use git. It's much better than the pain of
> cvs
> > or svn.
>
> Mozilla is migrating to Mercurial.  They rejected git; I forget why.
> It's early days for peer-to-peer source control, but based on my Darcs
> experience, in principle I'm a fan.
>


My 2 cents.

Distributed is the right way to go in my opinion.

Git and Mercurial look like they have the most mindshare. I believe
these will be the two dominant players by far in the coming years.

I think Linus pointed to some scalability problems in Monotone and I
think others have pointed to performance and memory usage problems
with Bazaar (OpenSolaris?, Mozilla?). I haven't seen much mention of
Darcs except for the 'dreaded exponential merge problem' and being
written in Haskell making it harder to port.

I would recommend going with either Git or Mercurial. However, the
Windows story is currently pretty minimal with Git. I think Cygwin is
still the best supported way to use Git on Windows, though I've read
there is now a working Msys port. However, both of these options will
be unacceptable to most Visual Studio users. With the CMake audience
and funding being heavily slanted towards Visual Studio, I would say
Git in its current state would be a bad decision for CMake. Until
something like a 'TortoiseGit' appears and becomes usable/matures, I
would rule out Git.

That leaves Mercurial. They do seem to have a TortoiseHg with a
'batteries included' installer which makes it much more viable for the
Windows story.

>From a user standpoint, Git and Mercurial are almost extremely similar
in core interface and feature sets. Most of the differences seem to be
implementation details.

Thanks,
Eric