Re: One repository, multiple products?

[Dennis Jones]

Thanks for replying, Rob.  Comments follow...


"Robert Clark" <address@hidden> wrote in message 
news:address@hidden

>> Obviously, this won't match the repository, which for the above
>> hierarchy would probably look something like this:
>>
>> /repository
>>     /trunk
>>         /shared sources
>>         /product A
>>         /product B
>>     /branch x
>>         /product A
>>         /shared sources ??
>>     /branch y
>>         /product B
>>         /shared sources ??
>
>
> Actually, for CVS, the repository might look something like:
>
> /repository
>    /shared sources
>    /product A
>    /product B
>    /3rd party
>        /library A
>        /library B
>
> with the branches and trunk being contained inside each file in the
> repository.

Yes, that is true for the actual physical implementation of the 
repository -- I intended to describe a *logical* representation of the 
repository (from a developer's perspective).


>> Another issue that comes out of this is how to checkout all of the
>> code necessary to build all of the products in their various
>> version configurations.
>
> There is no single, magic CVS command or configuration setting you can
> use that will cover this.

I suspected as much.


> What I do in situations like this is create
> a shell script/batch file/Ant file/makefile/whatever that I add to
> the root directory of the project.

> This script (which is version
> controlled along with the rest of the product) knows how to check out
> the correct version of the rest of the code as necessary.

> With they layout above, I generally tell people:
>
>   - checkout whatever branch of Product A you want into an empty
>     directory
>   - run the update_sanbox script in the root directory of the
>     project.
>
> That update script is written so that it checks out all the correct
> branches or versions of the shared common and 3rd party libraries to
> the correct location in the developer's sandbox.

Ah, I see.  So a checkout of any particular product requires two checkouts: 
the first to get the required branch for your product, then a second 
checkout using the product's 'update_sandbox' script to get the appropriate 
branches of its dependencies.  Then if the product's dependency on a 
particular version of another product changes to some other version, then 
you just change your product's 'update_sandbox' script so that it refers to 
the appropriate products/branches for its dependencies.  That makes sense, 
though it could lead to significant subtree duplication (if multiple 
products/branches use the same dependencies) -- but I think I could live 
with that.

Thanks a lot,

- Dennis