Revision control advice

[Chad Perrin]

On Fri, Dec 23, 2011 at 09:23:22AM +1030, William Brown wrote:
> On 22/12/2011, at 20:06, Matthew Seaman wrote:
> > 
> > svn vs git vs mercurial
> > 
> > svn has the model of a central repository that everything has to
> > communicate with.  This can be attractive in a commercial environment as
> > it implies a degree of central control over all of the project source code.
> > 
> > git is much more a peer-to-peer system.  This fits with a disparate
> > group of projects all proceeding pretty much independently.  There's
> > also a potential advantage if all your developers are not at the same
> > location and will not necessarily have access to central office systems.
> > 
> > mercurial unfortunately I'm not that familiar with, but it uses a
> > distributed model like git.
> 
> I would advise staying away from mercurial (aka hg). It has a lot of
> issues with corruption of repositories. Git does the same and is a lot
> more mature and stable. 

Uh . . . what?  Please provide a source for that claim.


> > 
> > Other criteria, like windows support, are not anything I have much
> > experience of, but by all accounts svn and git are pretty well served.
> 
> Again, git wins here. It has good support on windows, as well as with
> graphical tools on windows. 

How does TortoiseGIT improve on TortoiseHG?  I'm curious.


> 
> You can use git like SVN if you push to the master after every commit
> though. I also have found git's support for merging to be a lot better.
> Additionally it stores branches and tags as metadata on commits rather
> than svn's "dumb" tag / branch system where you just copy the full repo
> to the side.

For the vast majority of purposes, distributed VCSes like Fossil, Git,
and Mercurial are quite superior to CVCSes such as Subversion.  There are
cases, however, where a truly centralized system is more appropriate.
These are typically cases where division of labor is very starkly defined
and a strong central control over everything needs to be maintained even
when the people working out at the nodes of the system might be tempted
to follow a different, ad-hoc process of their own.  For those cases,
something like Git (or Fossil or Mercurial) simply will not do.