Re: Need advice about revision management

[Paul Sander]

>--- Forwarded mail from address@hidden

>Frank Langtind wrote:
>>
>> Our company is in the process of changing from RCS to CVS for revision
>> control and I'll need some advice to make it as good as possible.
>>
>> Our work in divided in project groups that work with modules and project
>> groups that work with products. The module projects are arranged like
>> this:
>>
>>
>> module1/doc/
>> src/
>> qa/
>>
>>
>> Our product projects use some of the modules and is arranged like this:
>>
>> project1/doc/
>> src/
>> qa/
>> import/module1/
>> module2/
>>
>> The import/moduleX directory within the product project contains only the
>> source from the moduleX (not documentation or qa stuff).
>>
>> This is obtained by using the "modules" file and work great. When we
>> check out the product projects, all required module sources are checked
>> out like expected.
>>
>> Since the modules are maintained independently, they have different
>> releases.
>>
>> Since different products use different releases of the same module (ie.
>> due to backward compatibility issues) we would like to specify which
>> releases a product should use. Like:
>>
>> Product1 should use module1 REL2_1, module2 REL1_4, module3 REL1_2, etc...
>> Product2 should use module1 REL2_5, module2 REL1_3, module4 REL2_2, etc...
>>
>> I could not find any way of doing this in CVS. Hopefully I have missed
>> something ;)
>>
>> I'm sure there must be other people having the same problem. Anyone care
>> to suggest ways of doing this, available scripts to help out, or maybe an
>> alternative methodolgy (after all we are in the process of changing..).

>AFAIK, the only way to do this is to have a script (possibly part of your
>build process) which issues "cvs co -r REL_WHATEVER" commands.

>Then you keep that script in your project directory, and it defines what
>branch/tag you use with the project.

>--- End of forwarded message from address@hidden

I would abstract it out further and write a single script that interprets
a data file that maps product/release pairs to a list of module/tag pairs.
Since tags represent branches or versions, this mechanism offers huge
flexibility in automating large numbers of variants.

The down side is that it doesn't scale well if there are huge overlaps
in the product/release definitions.  In that case, introducing a macro
preprocessor such as m4 or cpp to facilitate reuse of module/tag pairs
across many definitions could simplify maintenance of the data file.