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.
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? Nick "Bo Berglund" <bo.berglund at telia.com> wrote in message news:pva1e2pc6djo3s6disk994frqthcv7k0cc at 4ax.com... > On Mon, 14 Aug 2006 11:58:33 -0400, "Nick Duane" <nickdu at msn.com> > wrote: > >>It appears you can branch any module, but does it make sense to branch >>anything but a 'root' (top level module in repository) module? > > Yes, of course. You might for instance want to test a certain > development idea that you are not sure will lead anywhere and then it > even makes sense to branch a few individual files and keep everything > else on trunk. > >> >>Our project consists of several applications and several static libraries >>that most of these applications make use of. Currently when a release is >>done only the applications which have changes are built and released. I'm >>not sure if this is the best approach, as when I started working on >>cleaning >>up the build several applications no longer built because of changes that >>were made to the shared libraries. > > Welcome! THis is one of the reasons to use virtual modules instead! > We have many applications that we need to maintain all the time. They > have their own sources but they also use a lot of common code. > So what we have done is to create a virtual module (using the > CVSROOT/modules file) for each of tghese applications. > The sources needed are checked out to subfolders below the application > main folder using ampersand modules so we get a structure > approximately like this: > > application > |- source (main sources for the application) > |- common > | |- classxx > | |- classyy > | |- classzz > | |- utils > | |- libs > |- bin (where the executable go) > > Each such subfolder is defined according to the needs of the > application and from the utils dir we only grab exactly those files we > need for this particular product. > > We make sure that all project references are relative to the project > file in the source dir (..\bin, ..\common\utils etc) > > Now the module is ready for prime time and when we work on it we do > all of our tagging and branching from the top folder (application), > which means that tyhose files that came out of common areas also get > tagged properly and we can then retrieve the exact sources later that > we used earlier for a certain build. > > The only case where this scheme does not work well for us is when we > need registered files in our projects, for example type libraries. > Essentially you can have 2-3 projects you are working on in different > modules and then the same files (for example a type library) will be > checked out to several locations (and that does not matter much). > The problem is that when you work on App1 for a bugfix on Release1 you > might need an earlier version of the type library and the other app > needs the current version and both cannot be registered at the same > time in Windows.... > But this is not really a CVS issue. :-) > > HTH > > /Bo > (Bo Berglund, developer in Sweden)