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.
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)