What are the best practices for managing source code?

Question

We are a geographically diverse team of software developers working in the ERP system. We use SVN as a version control system. We have 4 environments before the code goes into the production system.

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

We are currently facing the problem that one file has 4 changes. The client wants only 2 changes to be released in X (only 4 major issues and 4 minor issues).

The problem we are facing: Too many branches. complex manual merge. losing or rewriting another user's code.

Can anyone decide how to solve this problem using SVN as the best tool he is.

Thanks and respect, Kedar Hookery.

Answer 1

Perhaps the process of how to get the code in the main branch will help more than another tool (except for the version control system with good diff / merge).

It depends on your process, but usually:

• It’s good practice for larger teams to have a separate branch for a new Function / Fix
• before releasing the code, the main line will output the last one, open its branch and run all the tests to make sure that all this works.
• If the team is large, you may have to consider the release manager - the person managing the releases and just freezing the main branch and controlling the order in which the functions go to
• even better, there are release branches and the person who is allowed to merge new functions in it, developers send a note that the new function is ready and one person merges the changes into the main branch
• release release before release and launch tests for iron bugs, do not allow new features only bug fixes when you are close to the release date.
• depends on the number of commits, but you can create smaller releases that are more tested for setting stages and functionality that you need to know to work at each point of release

In the end, whatever the exact process, the main thing is that the developers understand the procedures, and someone applies them.

Answer 2

One of the first places you may have already consulted: Versioning with Subversion . Also check out the list of books specified by Subversion Dev Team

Answer 3

First of all, read the following: 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 need to deal with all the different cases in the life of the project), there is a lot of pain when you start merging, if the branch lasts long enough, merging is a whole The "project" in itself ...

Of course, the best methods are useful, but it would be nice if the tool made it easy to enforce some of them.

I was recommended by Mercurial and am currently studying it to replace SVN, it is distributed by design, has (I said) a better merge tool and better / simplified branch / repository management, so you might want to explore it as well.

Answer 5

What you are asking for is unified change management, and that Subversion does not work very well (IMO). Change management will require some manual effort. But assuming you have decent problem tracking systems, here's what I worked for:

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 the bug has been fixed and fixed in the patch release, you will remove the old -issue # branch. This prevents the branches from getting out of control, but allows you to keep small changes in the settings.

Support devices can be enforced if the outlet trunks can only be accessed by integrators. Using subversion via apache: Subversion / Apache permissions , you can create a group of integrators and set the following permissions for 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 merger is small, well monitored, and only a small group of people can merge. However, this creates a bottleneck in your merger team. I have never worked with a large git / mercurial command to see how this works.

You would also use something similar for feature fixes, but instead, instead of your outside line.