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

[Nick Duane]

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?  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?

Thanks,
Nick

"Bo Berglund" <bo.berglund at telia.com> wrote in message 
news:hih1e2tkj1lm50nda0t8a8eis4br2vn52v at 4ax.com...
> On Mon, 14 Aug 2006 14:13:22 -0400, "Nick Duane" <nickdu at msn.com>
> wrote:
>
>>Thanks.  I was actually looking into modules and then modules2 to see if
>>that could help out with this situation.  I had planned to do something
>>similar to what you have done.  However, some of the people in the group 
>>are
>>concerned with the duplictation of source code (even though only one copy
>>would exist on the server).  It also appears that modules2 is something
>>specific to cvsnt so if I'm stuck with cvs 1.11 then I guess I have to use
>>modules instead.
>>
>>How do commits work on the ampersand modules?  Do they go back to the 
>>module
>>they correlate to on the server?  What if we want to create an App1 branch
>>called b-3-8 and an App2 branch of b-3-8 and both make use of shared 
>>static
>>library lib1?  Do they both attempt to create a branch b-3-8 on lib1?
>>
>
> Duplication of code is zero because you *have* to view the code base
> from the repository side. Duplicated *use* of the single source code,
> however is pretty much what this is all about.
>
> A branch is just another type of tag and it is put on the file(s)
> without much fuss. I don't think you should worry too much about the
> branch creation...
> And of course the whole idea with using modules is that you tag off of
> the top of the checked out module so that all of the files involved
> get the tag (normal or branch) at the same time.
>
> Commits done on the top level will recursively go down the tree and
> commit all files that have been edited. Typically the common or shared
> files are never or seldom edited so the commit won't affect them (only
> changed files are committed).
> And the virtual module is just a convenient way to assemble the files,
> the true location is known by CVS and this is where they will go when
> you commit too.
>
> You can't create a tag if it already exists (or rather cvs will accept
> the command but do nothing).
>
> HTH
>
> /Bo
> (Bo Berglund, developer in Sweden)