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.
Keeron Modi wrote: <<<<< 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. >>>>> I could be wrong but I don't think the problems you are describing are practically going to happen. When developer 2 tries to commit after merging to the HEAD they will, I think, get an error that they are not up to date and the commit will be aborted. This is assuming files are shared between developer 2 and developer 1 who beat them in for changes. But I wouldn't do things this way anyway - too many branches and tags. Why not allow the HEAD to be the development branch for everybody on the project and branch off stable code at release time for maintenance work? Before any commit it is standard practice to update and if there are changes brought in recompile and retest. This way developer 2 will get developer 1's changes and be able to resolve conflicts before they commits their mods. If a person needs to back up they could update to a specific date and time they knew was good. CVS can tell you what changed between date1 and date2 or you can use scripts (some publicly available) to tell you and/or create change logs. If you run nightly builds, which I think every serious software project should, you could tag at each build and use those as update points in case problems occur. We build nightly but do not tag nightly FWIW. This really gets into software engineering process which is different for everybody and probably why I didn't see a lot of responses. I personally think the heavy tagging you have outlined above will be more error prone and confusing than simply letting the HEAD for a project be the place for development. 1. cvs checkout ** gets you the HEAD by default 2. mod 3. compile/test 4. cvs update 5. resolve conflicts if any 6. recompile/retest if merges were brought in 7. cvs commit 8. check next morning's build log to confirm mods passed the build Have you seen http://cvsbook.red-bean.com/? That's a good introduction into using CVS and touches on the software management issues and best practices you are running up against. > * 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. You can do this easily with CVS's loginfo support and some simple scripting. Many, many CVS installations automatically send emails on commits. --Aric Aric Czarnowski Unimax Systems Corporation 612-204-3634