[cvsnt] Project structure in repository as it relates to branching

Bo Berglund bo.berglund at telia.com
Tue Aug 15 00:27:20 BST 2006


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)


More information about the cvsnt mailing list