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.
On Mon, 14 Aug 2006 17:22:26 -0400, "Nick Duane" <nickdu at msn.com> wrote: >I have app1 and app2 both with virtual module lib1. We're releasing both of >these application into QA for our 3.8 release so I want to tag them both >with tag t-rel-3-8. Does this work? Not really, if you have different apps you don't want to mix the tagging between them. We have a naming convention for branch tags that is like this: Branch_<application>_<release>_<date>[_issuenumber] example: Branch_WSMAdmin_1-0-2-45_20060814 You should somehow put the application name into the tag because in principle tags are repository-wide thingies and you could really have the application files spread out all over the repository without you even knowing (if you did not author the modules file definition). So it is not a good idea to have two application modules base a snapshot in time on the same tag name, especially not if it is a branch tag. But even if it is 'just' an ordinary tag it is no good, because if the file state on which the first tag is set is not the same as when you set the next one the effect is that the original position will be lost. Any given file can only have one single revision with a certain tag name. So when a file is again tagged with the same tag name cvs moves the tag to the new revision and you lose the original one. (The tag move is an option for cvs tag but is often set). >If so, what is the outcome? At some >later point in time bugs are reported in both applications so I branch both >of them at tag t-rel-3-8 and call the branch b-rel-3-8. Does this work? >What is the outcome? The modules feature appears to hide the underlying >structure of the repository, which sounds good. So the developer working on >app1 thinks he/she has their own copy of lib1 and the developer working on >app2 thinks he/she has their own copy of lib1. They each make separate >fixes to lib1 contained within their app. They commit their changes and tag >the release. What is the result? Does the b-rel-3-8 branch of lib1 contain >both fixes? If a fix is made in shared code then the first person committing his changes will be able to do this, but the second person will have a local version of the file that is not up-to-date anymore so he needs to do a cvs update first to make sure he has a tip revision (this will merge in the changes made by the first person to his copy of the file). Of course if this happens it is prudent to check if the file still builds OK before committing. But after the second commit the file now contains both fixes. HTH /Bo (Bo Berglund, developer in Sweden)