Re: Repository Layout - Product Suites

On Fri, Feb 18, 2005 at 09:59:35AM -0000, Butlin, Jason (UK - Epsom) wrote:
> We've got a product suite that contains a number of individual programs,
> which can be released individually. Obviously, as with most projects,
> there are a number of shared files used by all the products. My problem
> is that I'm struggling to determine the best way to organize the
> repository in such as way that the branching of the projects is least
> painful.
>
> We'd need to cater for the ability to branch some components for an
> individual release, and allow developers to easily go back to a previous
> version of a specific component for bug fixes. This is made more
> complicated by the shared code, which would obviously have to be
> branched every time a component was branched.
>
> If the suggested repository structure is followed, then we would have
> something such as the following
> /svn/repos/root/projectA
> .../trunk
> .../branches
> .../tags
>
> /svn/repos/root/projectB
> .../trunk
> .../branches
> .../tags
>
> /svn/repos/root/shared
> .../trunk
> .../branches
> .../tags
> If we release projectA, we would have to branch projectA and also branch
> shared, but as they're going to separate destinations, they'd have
> different revision numbers. So for a developer to fix a bug, he'd have
> to create a top level directory, check out the required branch of
> projectA into that and then checkout the required version of shared.
> Both would be treated as separate working copies, and I'm not sure this
> would really flow with the developer.

I think this would be the way to do it. Tag the shared code to make
"releases" of it, then it's easy to pull in a specific release into your
projects by using svn:externals or by creating a symlink. It would only
have to be done by one developer as Subversion supports these features.
Is this a feasible way?

> The alternative approach would be to place the trunk, branches and tags
> directories above the project levels. This would make it easier from a
> management point of view, in that everything is controlled from a single
> root point. However, you then get the issue (if it is an issue) that
> creating a branch for a release of projectA would also include the files
> of projectB at that point in time, which could be in any sort of state.
> I realise this is a cheap copy, but if a developer were to checkout a
> branch for bug fixing projectA, they would also get the unnecessary code
> for projectB.

I don't fancy this way of doing things. It seems too messy to me to have
all your projects in one trunk. But then again, thats just my personal
opinion.

> Has anyone got any experiences of dealing with a code structure like
> this that can offer some insight to the advantages of different
> approaches

I believe this topic has been discussed more than once on this list so
you may find valuable information in the archives. F.ex. in this thread:

<http://svn.haxx.se/users/archive-2004-12/1215.shtml>

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