[Top][All Lists]
[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.
**********************************************************************
- Organization tips, James McTavish, 2003/06/03
- RE: Organization tips,
thomas . maciejewski <=