RE: Organization tips

[Sylvain Lemieux]

Hi James,

I am not a cvs guru, but as a quick thought, I would suggest to look at
the "modules" administration files. In two words, it allows you to
create "pseudo module" (and few other things) that are made either from
other module of specific files contained in those modules. When you
checkout the "pseudo module", in fact you will checkout a collection of
source code as define in the "modules" files

Something like:
ProductA &Module1 &Module3 &Module4a &Module5b

Should do what you want.

The Apendix C.1 of the cvs manual provide better documentation than me!
:)

Hope that helps!
--
Sylvain Lemieux, ing.
PCI Geomatics Inc. (The french connection)
On ne peut tomber que si l'on essaie de marcher
Every rain cloud has a silver lining


> -----Original Message-----
> From: address@hidden
[mailto:info-cvs-
> address@hidden On Behalf Of James McTavish
> Sent: Tuesday, June 03, 2003 5:24 PM
> To: address@hidden
> Subject: Organization tips
> 
> Recently we have decided to move our code base to CVS to manage
versions
> and releases.  We have a bit of a unique situation however.  We
produce
> firmware and a single bit of code gets used across several displays.
> For instance there might be:
> 
> Module1
> Module2
> Module3
> Module4a \ Can only have either Module4a OR Module 4b
> Module4b /
> Module5a \ Can only have either Module5a OR Module 5b
> Module5b /
> 
> Plus code that specific to a single application.  A couple of products
> could be:
> 
> Product A
> ----------
> Module1
> Module3
> Module4a
> Module5b
> Stuff Specific to Product A
> 
> Product B
> ----------
> Module1
> Module2
> Module4b
> Module5b
> Stuff specific to Product B
> 
> I would like several things out of this if possible:
> 
> 1) Each product would have to be able to be fetched in one command and
> if possible all the files would appear in one directory (so we don't
> have to change our build scripts) or the modules would appear in a sub
> directory eg:
>       Product A/
>               Module1/
>               Module3/
>               ...
> 
> 2) When we fix a bug or add a feature to one module, the revision is
> incremented, and any product that uses that module will begin using
that
> new version (except when a release is tagged)
> 
> 3) Moving files between modules/product specific code should be as
> "easy" as possible.
> 
> Right I can only see doing things a couple of ways:
> 
> 1) Put all files in one CVS module and create a bunch of aliases
> specifying the file names that are required for a product and other
> aliases for individual modules.  This isn't so bad since we only have
> 10-20 files per product.
> 
> /CVSROOT
> /CodeBase
> 
> and the modules file would contain:
> 
> ProductA CodeBase/file1.c CodeBase/file2.c CodeBase/file3.c ...
> ProductB CodeBase/file1.c CodeBase/file4.c CodeBase/file5.c ...
> ...
> Module1  CodeBase/file1.c
> Module2  CodeBase/file4.c CodeBase/file5.c
> ...
> 
> 2) Seperate the files into CVS modules and specifiy aliases
> 
> /CVSROOT
> /ProductASpecific
> /ProductBSpecific
> /Module1
> /Module2
> 
> and the module file would contain:
> 
> ProductA ProductASpecific Module1 Module2 ...
> ProductB ProductBSpecific Module1 Module3 ...
> ...
> 
> Currently I'm leaning toward method #2.  Any suggestions or comments
or
> better ways to do this would be greatly appreciated.  I've searched
high
> and low and all the organizational tips I've read are geared for
> mutually exclusive projects.  As far as I can tell our situation isn't
> too common.
> 
> --
> James McTavish <address@hidden>
> Matrix Orbital
> 
> 
> 
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs