Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Subversion Re-education actually convinced me, but for now I'll stick to svn - mastering the use of a very popular tool can't be bad.

To date I've not used branching/merges in production code, now I decided to give it a try in a small team environment.

I'm afraid of suffering the same pain as the described in Spolsky's article. Is there a "right" way of working with branches in svn?

share|improve this question
add comment

2 Answers

up vote 4 down vote accepted

The most important part of working with Subversion branches is to merge from trunk often. Daily at a minimum, more if possible. The converse is also true - merge to trunk often - once features can go to trunk, merge them.

The more branches diverge from each other, the more merging becomes hell.

The longer you take between merges, the more files you will have to merge, the more chances of conflicts and the more chances that people will not recall the details of changes (meaning that making the right call on a conflict can become very difficult).

You will also need to decide on a branching strategy - this is not something that you will need to tailor to your team and workflow and will probably need to tweak as you go along. Interesting presentation here (pdf).

share|improve this answer
add comment

Branching always begins with fear that merging will break things or leave unnoticed bugs for long.

However, it is the most essential element for a reasonably sized product or project. Here are the few distinct categories where branches are a must - they are :

1. Branch post release
This is done to maintain post release patches. these patches are essential to support current versions in the market till next major releases are still not ready.

2. Branch per Task or component Here a few independent groups are given the branch that they keep check-in while rest of the team (or other branches) doesn't have to accept any work till entire new functionality or project is completely finished and merged to trunk.

3. Branching for special customer support Here a few branches are created to support only for a specific (set) of customers.

Branching and merging begins with some fear always, but in my experience, as people begin to put disciplined code, it becomes indispensable for any large development.

See URLS below for more details.

http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html

http://stackoverflow.com/questions/631900/branching-hell-where-is-the-risk-vs-productivity-tipping-point

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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