Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Hi everyone, We are planning on using CVS throughout our company and the projects are huge (40+ products, 100+ sub projects, probably around 1000 developers all over the world) (Had VSS to start with .. and now trying to move onto CVS) .. So planning out the process documents .. and we run into Branching and Merging issues. I'll try and explian a simple example and would like your input on whats the best thign to do: 1. A dev creates a branch off the "MAIN" trunk called "Branch_A" 2. A second dev creates a branch off the main trunk called "Branch_B" - same point as what DEV 1 did 3. Both devlopers continue work on their branches . and at some point, Dev1 is done with his changes .. and decides to merge onto MAIN 4. Bcoz we follow "heavy" tagging .. the dev tag his "final" revision on "Branch_A" as "Merge_from_Branch_A" 5. Checks out the "HEAD" of MAIN branch 6. Tags this revision immideatly with the tag "Pre-Merge_Branch_A" so that he knows what he is merging ... 7. Does a CVS update -j "Merge_from_Branch_A" 8. During the update, he got conflicts . so he is busy resolving these conflicts .. 9. BUT ->>> (this is the fun part) Developer 2 in the mean time does his merges on the HEAD trunk and now suddenly the HEAD is not what it used to be. Its changed. But developer 1 has an old head now. 10. Dev1 resolves the conflicts and merges his changes after a day. 11. Tags is "Merge_to_Branch_A" (If anyone using viewcvs/cvsgraph - this will help us draw pretty merge lines between the source and destination revision) 12. From above, the MAIN branch is Broken ! .. since what the "dev2" checked in is not in the last revision of MAIN . because developer1 merged his changes and that became the tip/head. This clearly is a bad situation. Also considering we will have lots of branches (for each bug, there might be a branch created and some devs working on that branch), - branches for different projects, maintaince lines, activity lines, etc . Lot of merges going on .. so whats the best situation to avoid the problem I just stated about ? * We cant use the "locking" feature .. (while a merge is going on, lock the branch) .. coz then you might as well say "Why not use VSS :-) ? " * We can have the "dev1" email all the groups working on that branch to not checkin anything until his merge is done. This takes away the meaning of parallel development and shipping products constantly and also working on other projects at the same time. * There is another alternative I can think of is .. the Dev1 does a "pseudo-commit" (passing -c option with cvs update).. and makes sure his code is not conflicting when he is doing the merge. That way the time it takes to merge is really small .. so there is very very less chances of someone putting in a revision while he is merging his changes. * Another one (similar to the 'email' suggestion) is anyone merging changes (a final commit on the branch) should email everyone in the group that the "Tip/Head" is changed .. so they can update their sandboxes . hence they will always merge their changes with the latest head revision. Although I think emailing would be a problem since often you have a huge archive/repository with lots of projects going on .. It would be hard to coordinate stuff thru email among lots of people. Any suggestions on this matter ? I am sure people must have encountered this problem in a big company . but not sure what the tagging/merging methods are . Along with the "source" and "destination" tag, we "pre-merge" tag, "branch point tag" on the parent branch and the actual branch name .. so 5 tags to be created in the whole process. - Keeron