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

Bo Berglund bo.berglund at telia.com
Mon Aug 14 18:15:25 BST 2006

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>

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

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


(Bo Berglund, developer in Sweden)

More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook