Everyone that has worked on any type of long term software project has had the need to branch their code at one time or another for one reason or another. Currently the team that I am on had to branch both projects (1 team, 2 projects) in the same week.
Normally branching can be a pretty straight forward concept. You take the code base from the trunk and move all needed code into a branch so that if you need to make changes to the branch you can and allow yourself the ability to continue forward progress on the trunk.
My question for everyone is this. If there are multiple projects sharing some level of the same code base how should the projects be branched.
Here is a idea of how our code is laid out in VSS.
-> Common project 1 -- company wide project
-> Common project 1 Test -- Company wide test project for Common Project 1
-> Application 1 Root
-> Application 2 Root
-> Note: There are directorys here that are used by application 1 as well
When Team A did their branch, they ONLY branched the source that was under -> Application 2 Root folder and nothing else. Since they did not branch any of the shared code, the modified their build project to pull the code out of the trunk. This caused a big problem for our 'home grown' build machine (yea, i know... why home grown. We are in the process of switching to TFS). After about 3-4 hours of playing around we finally fixed the issue with the build machine.
When Team B did their branch, they moved EVERYTHING over into a new structure. By doing this they did not encounter any issues with our build machine.
Having never really worked on team that had multiple projects that are independent, but share the same code base I have never really given it any thought as to how to branch properly. In my opinion, when you do a branch ALL source that is needed for that branch should be moved. This will allow for NO contamination of code and less headaches.
What does everyone think? Did team A do it right or Team B? HELP
03-02-2007 6:59 AM