We have several subversion repositories: one for common code and one for each top level project. The top level projects have a svn:external link to the trunk of the common repository.
Before we build a release of a project we create a branch of the top level project and also create a parallel branch in the common repository.
How can we automatically ensure the svn:external property in the branched top level project points to the parallel branch in the common directory - currently it will be pointing to "trunk" in the common respository. We are currently having to manually edit this in the branched project.
Thanks
If I understand you, you want to make sure that foo
and bar
share the same branch. foo
is your master project and has an svn:externals
on it somewhere pointing to bar
. When you branch foo
, you want to make sure bar
is using the same branch. The only way to ensure that is to create your repository with the tags
and branches
directories at the root of your repository instead of at the root of the project (like most sites do).
Then you can use relative external references to point from the foo
directory that contains the svn:external
back to bar
. Also, if you tag foo and bar with the same tag, foo and bar will maintain their relationship:
$ svn propset svn:externals ../../bar common
If your branches were at the root of your repository, then the common
directory will be pointing to the same branch for foo
as it is on bar
.
The big problem with snv:externals
is that if you're not careful, you're pointing to an ever changing version of the directory you're linking to. Let's say someone did this:
$ svn propset svn:externals /projects/bar/trunk common
in my foo
project. I do a release and copy foo
to a tag. However, the common
directory that I've tagged will be modified when someone updates bar/trunk
. This makes it almost impossible to rebuild foo
.
When I use svn:externals
, I always make sure I'm linking to either a tagged version of bar
, or a specific revision, and if I am linking to a specific revision, I also peg my URL to that revision in case someone decides to delete the directory I'm linking to my svn:externals
property.
There's nothing in Subversion that will automatically update your svn:externals
properties, but you can search for all svn:externals on a directory tree by using
$svn propget -v -R svn:externals .
I've found that svn:externals
usually ends up being a bigger pain than it's worth.
Instead, I simply store the built object of bar
or a zipped up copy of the source in my release repository, and as part of my build procedure, I copy the object or zipped source out of my release repository.
I use Maven site repositories like Nexus or Artifactory as my release repository even if I am not doing a Maven project or even working in a Java based project. The local Maven repository provides all the tools you need to upload and download your dependent packages, plus Maven has the concept of release repository -- where the code never changes -- and a snapshot repository where you're planning on releasing the code, but it could change. This is helpful if you suspect that bar
could change because of stuff you need in foo
.