Re: Switching from Subversion to Git

[mikel evins <mevins at me dot com>]

On Aug 28, 2014, at 3:29 PM, Per Bothner <per@bothner.com> wrote:

> On 08/28/2014 01:14 PM, Duncan Mak wrote:
>> Hello Per,
>> 
>> Have you considered switching Kawa's code hosting from Subversion to Git(hub)?
> 
> For now, I'm comfortable with Subversion.  I don't see a major benefit to
> switching. (Also, we'd lose the nice sequential commit numbers.)  What do you
> see as the major reason(s) to switch?
> 
> If we switch, I prefer Mercurial to Git, mainly because I'm more familiar with
> it.  (Oracle uses Mercurial for their Java work.)
> 
> If we start getting more people working on and contributing to Kawa, then we
> might consider switching to either Mercurial or Git.

I've used all of them quite a bit. I use git day-to-day nowadays.

The primary advantages of git over Subversion, in my experience,are:

- when the repository server is down, or the network is unavailable, there is no interruption in your ability to use revision control.

- branching and merging are significantly easier and safer than with Subversion.

- git's faster.


The only advantage of git over Mercurial, as far as I can see, is that github uses git. Github is useful enough by itself to be a reason to consider using git. It's the reason I use git; without github in the equation, I prefer Mercurial.

git is generally faster than Mercurial, but we're talking about the difference between a few millseconds and a few tens of milliseconds in a typical interaction, so git's speed advantage over Mercurial is usually imperceptible.

There are disadvantages to switching from Subversion to git or mercurial. Sequential revision numbering is one, though as a practical matter I don't miss them. More important is that using a distributed revision control system is actually different enough to require some relearning, even is--as is typical--a project works from a de facto central repository.  You have to get used to the fact that, for example, checking your code in does not mean anyone else can see your changes. You must also push your changes to the shared repository. Similarly, pulling changes does not necessarily mean you'll see them locally; it depends on whether you normally use a form of the command that also checks them out into your local working directory.

All of this is easy enough to adapt to, but adaptation is required.