[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Project branches and product branches

From: Bailey, Darragh <dbailey_at_hp.com>
Date: Wed, 29 Sep 2010 14:14:44 +0000

Have an interesting issue with branching a product which is made of multiple components, each with it's own area in svn. Problem is probably mostly of our own making, and while there appears to be more than one solution, each has it's own problems. Before I go ahead and pick one, I'd just like to check that I'm not overlooking anything within svn that could make this much more straight forward for the developers.

Our SVN layout:
Project1/{trunk,branches,tags}
Project2/{trunk,branches,tags}
Project3/{trunk,branches,tags}
...
ProjectN/{trunk,branches,tags}

From this we release more than 1 product made up of different subsets of the projects. The original idea was that when we need to release a product, we made a stable release of each project that will be included and create suitable branches. When releasing the second product, if there are no changes to any of the shared projects since they were last released, then the second product would make use of the existing stable releases of these projects.

Each of these Projects have there own versioning, so the original idea was to create each project's branch should be the version the stable release of the project takes place at.

The problem comes with the impact to the developers, since each project has it's own versions, knowing which branch is associated with a release takes a bit more effort and can be confusing particularly if they need to implement a fix that requires a change to more than one project (does happen, although it's not particularly common as the projects are isolated and only interact between defined API's).

To get around this confusion I was looking at using svn:externals to allow a more mnemonic name to allow developers to easily find the correct version to work on:

i.e.
Project1/branches/1.0.0 <-- stable release
Project1/branches/productA-<product-version> -> svn:externals refering to 1.0.0
Project1/branches/productB-<product-version> -> svn:externals refering to 1.0.0

Thus if the developer is needs to implement a fix for productA that affects Project1, they would easily get to apply the fix on the correct branch.

The problem is that in general developers checkout the projects via eclipse as each project is a separate eclipse project. But svn doesn't allow you to checkout a path that is an svn:externals. You can checkout the directory above and have the svn:externals resolve, but you can't checkout directly on an svn:externals (i.e. svn co <svn url>/Project1/branches/productB-<product-version> will fail as the path doesn't exist according to svn). Also an svn:externals of "^/Project1/branches/1.0.0 ." set on the directory called productA-<product-version> will also fail with the message "svn: Invalid svn:externals property on 'productA-<product-version>': target '' is an absolute path or involves '..'".

So far the only solutions I have are
A) to release each project with a different version when being released for each product and then name the banches according to the product it is released for:

Project1 version 1.0.0 branched as: Project1/branches/productA-<product-version>
Project1 version 1.0.1 branched as: Project1/branches/productB-<product-version>

Where there may well be no differences between version 1.0.0 and version 1.0.1 except that they are released under different products.

B) Create a stable branch for each project based on it's current version
Create a toplevel directory called branches, and create a product directory underneath that uses svn:externals to bring together all the projects that were released with product and points to the corresponding stable release branch for the project.

Set an svn:externals on Branches/productA-<product-version>
^/Project1/branches/1.0.0 Project1
^/Project2/branches/1.2.0 Project2
^/Project3/branches/1.1.0 Project3
^/Project4/branches/1.0.9 Project4

And require the developers to switch to using something like TortoiseSVN or command line svn to checkout the product tree if they need to fix a problem with an associated released project and don't want to spend too long working back to what version of the project was released with which overall product.

Is there anything else that I'm missing (besides maybe not having used a <project>/{branches,trunk,tags} layout in the first place instead of {branches/product,trunk,tags}/<project>)?

--
Regards,
Darragh Bailey
Received on 2010-09-29 16:16:39 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.