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