repository layout for large project

[Sam Izzo]

Hi

I'm after some advice on how I should set up and manage a repository for
a large project.  The project is based around plugins (DLLs).  There is
a main application shell which has some base functionality, a set of
application plugins, and a set of minor plugins that are used by
application plugins (actually we call them modules but I'll use "plugin"
because of possible confusion with CVS modules).

So:

Project
   |-- Appshell
   |
   |-- Plugins
   |      |-- plugin 1
   |      |-- plugin 2
   |      |-- plugin 3
   |
   |-- Minor Plugins
   |      |-- minor plugin 1
   |      |-- minor plugin 2
   |      |-- minor plugin 3

Now ordinarily there's a basic off-the-shelf version of the product.  A
release of version 1.3 of the product, for example, would include
Appshell version 1.3, plugin 1 version 1.5, plugin 2 version 1.6, etc.
A release of version 1.4 of the product might include Appshell version
1.4, plugin 1 version 1.5, and plugin 2 version 1.8 (i.e. plugin 1
hasn't changed).

On top of that, some clients require specific changes to particular
plugins.  So they might purchase version 1.3 but then a custom version
of plugin 1 (based on the latest release version), so they might get
plugin 1 version 1.5-company A.

Clearly branching is going to help immensely.  The thing is where would
be the best place for the branching to occur?  Can one even branch a CVS
module at a sub-directory, or can branching only occur at the root?
Should the entire project be under one CVS module in the repository
(with appropriate sub-directories) or should each plugin be a CVS
module?  Should there be a branch of the entire project for each
customer?  That seems a logical way to do it, but the only thing with
that is that we might only be changing one plugin, and there might be
many changes to other plugins, so that seems a bit overkill because the
only difference between the off-the-shelf version and the client version
is one plugin, yet we have the possibility to change the entire code
base.  I suppose then it comes down to the fact that when we build a
release version we build the main stuff off the trunk and then build
that specific plugin from that branch and just forget about the rest of
the branch.

And then eventually we might want to merge a customer specific version
back into the trunk because it might turn out that the customer specific
version has changes that are appropriate to the off-the-shelf version
(i.e. they're things that apply to everyone and anyone).  Not to mention
we have to manage bug fixes for custom plugins and also the
off-the-shelf version.

Argh, I'm not sure!

Apologies if some of this is covered in the manual; I've been reading
and reading and I think I'm suffering from information overload :)
Double apologies for the long winded email!

Any tips would be muchly appreciated!

cheers
sam