Revision control advice
perrin at apotheon.com
Fri Dec 23 01:03:38 UTC 2011
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.
More information about the freebsd-questions