RE: CVS Server and 'Shopping lists'

[Jean-Claude Gervais]

Kevin,

        Thank you for taking the time to reply.
        You have correctly analyzed the scenario.
        Let me explain in greater detail:

        Say that ModuleA, ModuleB and ModuleC are general-purpose modules that
have their own development path.

        Each one of the modules is developed and managed separately.

        At important milestones which are reached by each module
non-simultaneously, tags are put across the modules.

        For example; in january, ModuleA reaches a point in its development
where it is christened "STABLE_RELEASE_v2_2"

        ModuleB on the other hand is at "STABLE_RELEASE_v3_1" and work in the
module is ongoing towards the next release...

        ModuleC is later tagged "STABLE_RELEASE_v0_9" in July...

        The situation is further complicated by the fact that three products
exist that all use these modules, but at different revision levels.

        Product1 (tagged "PRODUCT1_RELEASE_v1_0") is made up of 
                ModuleA "STABLE_RELEASE_v1_3"
                ModuleB "STABLE_RELEASE_v2_0"
                ModuleC "STABLE_RELEASE_v0_3"

        Product2 (tagged "PRODUCT2_RELEASE_v1_3") is made up of 
                ModuleA "STABLE_RELEASE_v1_1"
                ModuleB "STABLE_RELEASE_v2_2"
                ModuleC "STABLE_RELEASE_v0_5"

        Product3 (tagged "PRODUCT3_RELEASE_v1_0") is made up of 
                ModuleA "STABLE_RELEASE_v1_1"
                ModuleB "STABLE_RELEASE_v2_2"
                ModuleC "STABLE_RELEASE_v0_5"

        while Product3 ("PRODUCT3_RELEASE_v1_2") is made up of 
                ModuleA "STABLE_RELEASE_v1_1"
                ModuleB "STABLE_RELEASE_v2_2"
                but NO ModuleC

        As you can see, the products' development path is orthogonal with
respect to the modules' development paths. Hence the idea that each
product is in fact composed of a 'shopping list' of modules that can be
radically different for each product tag.

        The suggestion to use modules is a good one, but it has these
limitations: At some points in their development history, the products
may not only use the A, B and C modules at different revisions, but they
may even use other different modules and some modules may no longer be
used for a product depending on which version of it is being requested.

        Can the modules file be tagged also? Then the module definitions of
which you speak could effectively do the job as they would contain
different aliases depending on which version of the modules file you
retrieve, but in reality I do not think CVS works this way.

        As you've also correctly identified, a versioned script file that would
be retrieved from a tag and would then checkout the shopping list could
be a workaround.

        It is a good solution, but it would be of even greater value if there
was a way to achieve the result I am seeking in one operation,
tranparently, on the server...

Still, thank you for helping flesh this out. I fear I may have to go
with a script that processes from the client-side though...

Thanks again.

J


On Fri, 2006-05-19 at 13:56 -0500, Bulgrien, Kevin wrote:
> Tags are shopping lists that specify versions of individual modules
> when combined with the module definitions supported by CVS.  Modules
> need not be a name of a given file or directory, but is instead may
> be a name that specifies a conglomeration of various files and
> directories that make a useful view of a part of the repository.
> 
> See the CVSROOT/modules file format for where -d, -a and & are
> used.
> 
> # top-level source directories
> #
> product/blah product/blah
> platform/blah platform/blah
> resource/blah resource/blah
> resource/blah resource/blag
> resource/blah resource/blaf
> 
> # "shopping-list" modules
> #
> blah-platform -d . &platform/blah
> blah-product -d . &product/blah
> blah-resource -d . &resource/blah &resource/blag &resource/blaf
> blah -a blah-platform blah-product blah-resource
> 
> To get a sort of shopping list of things, do something like:
> 
>   cvs -d somepath checkout blah
> 
> blah is not a real module, but it is instead a list of items in
> CVS.  Surely using this in combination with tags will get you
> what you need?
> 
> The server cannot do additional checkouts for your client.  You
> could have a front-end for your client that could do what you want,
> but it would not be server-side.  The front-end could be a set of
> scripts, but it would not be transparent to the user.
> 
> Kevin R. Bulgrien