You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jonathan Hogg <jo...@onegoodidea.com> on 2004/05/05 08:48:08 UTC

Subversion pattern advice

Hi all,

I'm about to switch from CVS to Subversion for managing my companies 
projects, but I'm looking for some advice on the right Subversion 
pattern to match the way we currently manage our projects in CVS.

At the moment we make extensive use of module inclusion in CVS. Our 
code is split up into a number of components, each of which can be 
built separately (in theory anyway). We use a CVS module for each of 
these components. Components are grouped together into particular 
product builds with a product module which contains the build files for 
that product and includes the dependant modules for the product as 
"&foo" sub-directories. This way we can (and do) re-use components 
between different products.

I'm unsure of how to either achieve something similar with Subversion, 
or what pattern I should use instead. External references don't seem to 
cover what I want to do. As far as I understand them from reading the 
Subversion reference, they aren't integrated into the checkout the same 
way included modules are in CVS. In particular we tag/branch these 
products relying on the fact that CVS will recurse into included 
modules and tag/branch them too. Shared components are not "dropped" 
into products, they are shared live between the teams (continuous 
integration).

The best I can come up with is a structure along the lines of:

     /componentA/trunk
     /componentB/trunk
     /componentC/trunk
     /product1/{trunk,branches,tags}
     /product2/{trunk,branches,tags}

The trunk of product1 and product2 would contain the product build 
files and external references to the trunks of the components they 
depend on, say A & B and B & C respectively. Developers would check out 
the product trunks and work away, committing and updating as normal.

If I want to branch product1 I would copy /product1/trunk to 
/product1/branches/product1-foo, then remove the external references 
from it and copy the trunks of the respective components as direct 
sub-directories of this new branch. A developer would checkout the 
branch and work as normal. Integration can be done by merging to/from 
the respective trunks. A product tag would work in a similar way.

This seems easier than the alternative of tagging/branching each module 
separately and creating new external references for each tag/branch, 
but I've not tried it out yet so I'm not sure.

Any advice?

Cheers,

Jonathan


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org