What is the best practice regarding Source code managment ?

Question

We are geographically diverse team of software developers working on an ERP system. We are using SVN as a version control system. We have 4 environments before the code moves to production system.

I want to know what are the best practice, regarding BRANCHING, MERGING when using SVN in such situation.

Currently we face a problem that one file has 4 changes. The customer wants only 2 changes to be in X (yearly 4 main releases and 4 minor releases) release.

The problem we face are: Too many Branches. complicated Manual merge. losing track or changes overwriting someone else s code .

Can anyone answere how can one solve this issues by using SVN as a better tool, which it is.

Thanks and Regards, Kedar Hukeri.

Answer 1

One of the first places to start is one you may have already consulted: Version Control With Subversion. Also check out the list of books cited by the Subversion Dev Team

Answer 2

Maybe a process how to get code to main branch would help more than different tool (other than source control system with good diff/merge).

It depends on your process but generally:

• good practice for bigger teams is to have a separate branch per new feature/fix
• developer before releasing code to main line would pull the latest from main to his branch and run all the tests to make sure it all works
• if the team is big you may have to consider a release manager - a person to manage the releases and simply freezing the main branch and managing the order in which the features go in
• even better, have release branches and a person that is allowed to merge new features into it, developers submit note that new feature is ready and one person merges the changes into main branch
• freeze release branch before release and run tests to iron bugs, don't allow new features in only bug fixes when you are near release date
• depends on number of commits but you can create smaller releases which are more tested to establish milestones and functionality to be know to work in each point release

In the end, no matter what the exact process is the main point is that the developers understand the procedures and someone enforces it.

Answer 3

First of all, read this: http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

Answer 4

I share your pain, had the same problems with SVN, as soon as you start branching a lot( and you have to in order to deal with all the different cases in the life of a project ), there's a big pain when you start merging, if the branch lasts long enough, the merge is a whole "project" by itself ...

For sure better practices are useful, but it would be nice if the tool would allow to easily enforce some of them.

I've been recommended Mercurial and I'm looking into it currently to replace SVN, it's distributed by design, has ( I'm told ) a better merge tool and a better/easier branch/repositories management, so you might want to look into it as well.

Answer 5

What you're asking for is Unified Change Management, and that's something that Subversion isn't really designed to do well (IMO). It's going to take some amount of manual effort to manage changes. But assuming you have decent issue-tracking systems in place, here's what many places I've worked have done:

main branch (trunk)  - new feature development here 
  |- release-1.0  - locked release branch 
  |--- release-sp1
  |--- release-patches - patch release fix stream (new fixes merged here)
  |------ release-sp1-issue# - this is where you make your bug fixes 
                               before merging them. 
                               This issue# is the bug-id in your tracking system.

Once a bug is fixed and committed to the patch release, you delete the old -issue# branch. That keeps branches from getting out of control but lets you keep changesets small.

Maintainers can be enforced by making release trunks writable only to integrators. Using subversion via apache: Subversion/Apache Permissions, you could create a group, integrators, and set the following permissions on your project

project 
  |- branches  (everyone: rw) 
      |- individual-fixes
  |- release-branches: (integrator: rw, everyone: ro) 
      |- release-1.0-fixes
      |- release-2.0-fixes
  |- trunk     (integrator: rw, everyone: ro) <- new dev goes here!!!!
  |- tags      (integrator: rw, everyone: ro) 
      |- release-1.0
      |- release-1.0-sp1 
      |- release-2.0

Then each merge is small, well tracked, and only a small group of people can do merging. This creates a bottleneck on your merge team, however. I've never worked with a large git/mercurial team to see how this works.

You would implement something similar for feature fixes as well, but off your trunk instead.