This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Switching from Subversion to Git


On Sep 24, 2014, at 12:39 AM, David Pirotte <david@altosw.be> wrote:

> Hello,
> 
>> ... Here the workflow that is most commonly used on github:...
> 
> I am not using kawa, but I am 'lazilly' following the list [I use guile].  On this
> git related subject and thread, I'd like to recommend a git link I liked very much
> when I switched to git for my own projects and for helping projects related to guile
> [I'am currently trying to help, working on g-wrap, guile-cairo, guile-gnome and
> guile-clutter]
> 
> The link is this one:
> 
> 	http://nvie.com/posts/a-successful-git-branching-model/

I'll second your endorsement of this model. I've found it very helpful, and used it to help bring a small team up to speed on Mercurial, whose differences from Git are minor.

Git and Mercurial can be unexpectedly hard for experienced programmers to adjust to. They're not that hard to learn or understand, but a large fraction of new users seem to go through a phase where they just balk, and don't get how the VCS works or how they're supposed to use it. It was my experience that this reaction went away after a week or so with a little handholding, after which competence and enthusiasm rose rapidly.

DVCSes are not perfect. Nothing is. But there are two things that I find compelling about them: when compared to Subversion they are very fast for most operations, and, more importantly, when using a DVCS, you *always* have access to revision control. 

The CVS and Perforce and Subversion model is that there is a central repository, and you check things into it and out of it. The main disadvantage of this model is that if your net connection goes down or if there's a problem with the server, you lose access to revision control until the problem is resolved. That doesn't happen all that often, but its very rarity makes it even more of a pain when it does happen, because you most likely don't have ready-made strategies for dealing with it.

With a DVCS like Git or Mercurial, losing the network or the server has no effect on your access to revision control. You can continue to commit changes just as if the connection were still sound.

In order to make that work, DVCSes introduce a small extra level of complexity: the act of committing changes and the act of pushing them to a remote server become separate things. Similarly, getting changes from the remote server is not the same thing as checking them out into your working directory; there's an extra step. It can take a week or so to get used to that difference.

Once past that difference, though, the safety and convenience of having the VCS always available, even while you're out of network connectivity, is so nice that it's hard to give it up after you've experienced it.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]