how do I manage source code using SVN? branching, merging

Question

We are team of 4 developers/friends located in different locations. We all have started working on the a ProjectX and created branches A, B, C and D using Subversion.

we have just basic knowledge of version controlling the source code. Other day one of us just tried to merge Branch A with B,C, and D and B tried to merge with A, C, and D. (and they didnt even know how to merge it :D, just right click > merge > merge a range of revisions) We got some conflicts, solved them. Tried merging again, again right click .....) Conflicts again.

Now that all of the code has been messed up. we are having 4 different code copies (D missing B's functionality but having C's etc etc). So I went through lots of threads here on SO, read the SVN book and especially this article (how to branch properly) helped a lot in understanding how to merge branches and trunk. I think I have got a better understanding for the future. But how do I get out of current situation??

My questions are:

• As 4 of us are working on same project but usually work on different bits, should we just have one branch?? and then create 4 working copies and then commit and update only. Once we are ready merge trunk to branch, branch to trunk? as per suggestion in the above article
• Can you please suggest any work-flow so that we can get our 4 branches to the trunk and then I can take an export to start the version controlling from scratch again.
• Also I think if go again with 4 branches, should each of us daily/regularly update our branch and get changes from trunk (merge) and merge local changes back to trunk?? (instead of trying mergin branch to branch :-D)

Please suggest what work flow we should use? so that its a minimum pain in maintaining code. Thanks.

Answer 1

The safest strategy is to create a branch for each CR (Change Request / Task / Bug / etc). The flow would be like this:

1. A CR is given to a developer through a CMT (Change Management Tool, like Bugzilla);

2. The CR is analyzed. If it makes sence it is accepted and the developer creates a branch for it. The branch name could be something like:

   projectName_crNumber_crCreationDate_developerId

3. After the work is done (tested, commited, etc), the developer should lock the branch, so no one would change it, mark the CR as resolved (inform branch name at CR), and wait to the CM (Configuration Manager) to merge it to a build branch (along with other development branches);

4. After a certain number of CRs are merged into a build branch (build_xxx), this integrated version should be tested. If everything is OK it should then be merged to the truck.

5. A label could be applied each time the trunk achieves a certain goal/milestone (set of CRs).

Lots of details have been omitted. This is a workflow adopted by large teams with high quality standards. It may not be flexible enough to small groups. However, most of this tasks can be automated and scheduled with existing tools.

Answer 2

And another excuse to post a link to Eric Sink's source control howto.

This is far and away the best introduction to source control I've found and is relevant regardless of the tools you use.

Answer 3

I would not create a branch per developer. I recommend a continuous integration process where all four of you check out from a single "trunk" and merge changes frequently - many times per day. Ideally you would have a standardized build tool (e.g. Maven, Ant, etc.) and a build scheduler (e.g. Hudson, Cruise, TeamCity, etc.). Having these two tools on top of your SCM tool (Subversion) you can have a process continuously building all changes you check into the trunk and emailing all developers whenever there is a problem. This protects you from breaking the build through bad changes or merges while allowing you to keep a light-weight branching structure (i.e. one branch - the trunk).

Branches make it more difficult to integrate your code changes with that of your teammates. Branches should really be used for, well, branching - creating specially managed "branches" of your software. For example, if you are releasing version 1.0 of your software, it would probably be a good idea to create a 1.0 branch off of the trunk (after development but before releasing) so you have a place to maintain this version without impacting on-going development on the trunk (perhaps for version 2.0).

I recommend grabbing Pragmatic Version Control with Subversion. It's a pretty solid overview of SCM with specifics for Subversion.

Answer 4

If you are restricted to SVN, keep reading, if not, you sound like a prime candidate for DVCS like Mercurial, Git, or Bazaar.

For SVN, from my past experience it is generally best to keep the trunk where everything is merged into (See examples here). Each person should merge back into the trunk and then you merge from trunk to your branch. Merging from branch to branch in SVN seems like a bad idea.

Answer 5

Normally, with only 4 guys working on the code you don't need 4 branches. You probably don't need branches at all, just put it all into one trunk and work on that. Think of your checked out local working copy as your "anonymous local branch".

Branches are useful if you anticipate your code to exist in at least two versions for a certain time. For example, when you release version 2.0, and you want to start working on 2.1 but have to support 2.0 for the forseeable future. You could start 2.1 as a whole new project, but then you'd lose the ability to port fixes from 2.0 to 2.1 and vice versa. So you name one version trunk and branch from it.

Another scenario is when one of you starts implementing a new module or reimplementing an existing module, and knows it's going to take a while (longer than your usual commit cycle) and can't guarantee that it's not going to affect other people's code during that time. Then you let him branch, develop his thing, and then you figure out how to merge it back. Here again, you have one trunk you branch from and merge back to.

Answer 6

Generally, if you're all working on different pieces of the software, you'll find it easiest to work out of the same branch. If you're not commonly working on the same source files or on parts of the software that depend on each other, you won't find you frequently have conflicts when you update your working copies or a broken source tree when you commit.

Branches in SVN (as opposed to a distributed revision control system) are more intended for big, sweeping changes that are likely to either break your colleagues' code or require a lot of work (in which case you want to make many incremental commits that may not compile) or things like managing releases.

Go with a single branch (the trunk, as pointed out in other answers). When multiple people have to work on the same code, then whoever checks in second will fix the conflicts by hand. Fixing conflicts in one revision is much easier than trying to merge several revisions of changes into another branch that also has advanced several revisions since they split.

Answer 7

1. You should use one branch for main development. That is not actually a branch and is called "trunk". Each developer should commit changes to the trunk. You may need to create a branch when you make a code release or a major change in the program. Then if you make some changes to the branch (let say patch for the previous release) and want to have these changes in the main trunk too you should merge the branch back to the trunk.
2. I don't know any better way other than to go over your changes and manually merge to one code tree.
3. You should not go with 4 branches in your case. That's not the correct way to use version control system.