info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Organization tips


From: thomas . maciejewski
Subject: RE: Organization tips
Date: Wed, 4 Jun 2003 09:40:00 -0400

My question is how do you manage production branching over modules?

Like if I want to roll out project1 with uses module1 module2 and module3
and when I roll this out I want to create a production branch.  is there a
way to also branch the included module?   If not does anyone have a
solution for this?

Tom



                                                                                
                                                                 
                      "Sylvain Lemieux" <address@hidden>                        
                                                       
                      Sent by:                                              To: 
      "'James McTavish'" <address@hidden>,          
                      info-cvs-bounces+thomas.maciejewski=us.socgen.         
<address@hidden>                                                  
                      address@hidden                                           
cc:                                                                  
                                                                            
Subject:  RE: Organization tips                                      
                                                                                
                                                                 
                      06/04/2003 09:29 AM                                       
                                                                 
                                                                                
                                                                 
                                                                                
                                                                 




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



_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs







**********************************************************************
The information contained herein is confidential and is intended solely for the 
addresse(s).  It shall not be construed as a recommendation to buy or sell any 
security.  Any unauthorized access, use, reproduction, disclosure or 
dissemination is prohibited.
Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall assume 
any legal liability or responsibility for any incorrect, misleading or altered 
information contained herein.
**********************************************************************





reply via email to

[Prev in Thread] Current Thread [Next in Thread]