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

Copy externals when branching

From: iprmaster <iprmaster_at_gmail.com>
Date: Mon, 2 Mar 2009 09:35:35 +0100

Hi everybody,

I have a problem on how to handle svn:externals in case of repository branching.

Let suppose I would like to have a repository structure like this:

- repository root
...trunk
......dir1
......dir2
......dirExt1 svn:externals -> https:/path/to/an/external/repository
......dir3
......dirExt2 svn:externals -> https:/path/to/another/external/repository
...tags
......v20090101
.........dir1
.........dir2
.........dirExt1 svn:externals -r12345 -> https:/path/to/an/external/repository
.........etc.
...branches
......ourDev_20090101
.........dir1
.........dir2
.........dirExt1 (??)
.........dir3
.........dirExt2 (??)

My needs can be summarized as follows:

1) in trunk the svn:externals definitions should *always* point the HEAD versions of the external
repositories -> AFAIK this is automatically done if I define "unversioned" svn:externals

2) in any tag versioned svn:externals definitions have to be set: I have just discovered svncopy.pl, so this is
not an issue either :D

- now the challenge: if I define a branch (i.e. ourDev_20090101), I would like that some/all svn:externals
definitions are replaced by actual directories on *our* repository. On other words, once I have branched
our repository, the development of dirExt1 dirExt2 has to continue on it. However, it would be nice if later
a merge back to the trunk would be possible ;-)

Vendor branches may represent a solution, but they make more sense if you stick your whole
development to a stable version of the external libraries (like in the example given in the
SVN-documentation).

I am wondering it there exists a smarter solution... Do you know one?

Thanks,
Max
Received on 2009-03-02 13:59:14 CET

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.