10

My team at work is starting a new project, using Subversion as our VCS (you may consider this set in stone for the purpose of this question). We're still in the early stages of the project and are trying to agree on a branching model. Our previous project was based on a non-standard version model that led to issues when managing hot-fixes and patches to existing releases.

I've found different branching models to be rather complicated, but one model that I do understand fairly clearly is git flow. I'm curious how hard/undesirable it would be to implement a variation of this in Subversion. Obviously there would some difference in terms of people collaborating on branches. The feature branches would have to be centralized rather than limited to local repositories, but the other concepts of the model should be reproducable in Subversion as I understand it.

What would be the drawbacks or challenges to this approach. What I've heard is that in SVN "merging is expensive" relative to Git. But I'm not completely clear on what this means in practice or how it would effect our ability to use a git flow like branching model.

What would be the biggest concerns with this approach. Is there a similarly clear approach that is more natural in Subversion?

|improve this question
12

Gitflow is based on the best practices of source code versioning and branching. A very good article on this is Advanced SCM Branching Strategies

The point that Vance makes in the linked article is that different branches have different roles. He identifies the roles of:

  1. Mainline (all branches from here)
  2. Development (where development work is done)
  3. Maintenance (where maintenance work is done)
  4. Accumulation (Bringing things together in preparation for release)
  5. Packaging (packaging the build for the release)

In gitflow, these are:

  1. Develop
  2. feature branches
  3. Hotfix branches
  4. Release branches
  5. Master

The article on branching was written with Perforce in mind. Perforce is a centralized VCS, much like svn is. The patterns of branching that he describes perfectly map to svn.

The key to realize is that its not how does gitflow get ported to svn, but rather how to apply the same fundamental concepts of branching and the roles of branches to different VCS structures.

I would strongly recommend reading the article, I can't do much credit to it. The way things are described in there are based off of a trunk/mainline build philosophy that you will find it easy to map svn to.

|improve this answer
  • 1
    Going back to ideas leading the design of gitflow is a clever enhancement of the original question! – user40989 Dec 12 '13 at 12:00
  • @user40989 I'm not sure if Vincent Driessen (nvie) had read the article or not that put forth this concept of branching, or if he rediscovered this on his own. Either way, the recognition of what the necessary roles for a working flow through version control make it easy to see the similarities between the approaches and best practices. – user40980 Dec 12 '13 at 15:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.