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.
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.