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

Externals or vendor branches?

From: Jeroen Coumans <jeroen_at_jeroencoumans.nl>
Date: 2004-08-10 13:35:37 CEST

Hi,

We use the three-tier directory layout (branches, tags and trunk) for
our repository. We use the trunk to track an external vendor branch, the
tags to maintain external releases and the branches for our local
modifications. A branch is essentially the trunk and an added
configuration file; sometimes a file is slightly changed. Currently, we
use the "vendor branches" approach, as described in
<http://svnbook.red-bean.com/svnbook/ch07s04.html>, to upgrade the trunk
and to merge it with the branches.

This setup is working fine, but it doesn't scale well. For example, we
now have 20 branches. To merge upgrades from the trunk requires checking
out each branch and merging the changes. Apart from the diskspace
requirements and time spent on checking out & checking in, You can see
how this becomes an increasingly large operation as the number of
branches grows.

So I'm trying to come up with an easier scheme. I'd like to be able to
create branches which pull in the contents of /trunk/, except for files
which are locally modified or added. In that scenario, I can maintain
unlimited branches, and would only need to upgrade the trunk in order to
upgrade all branches. Is this scheme possible? And would it be
advisable? I'm not sure if I can use svn:externals for this, since it
mostly seems to talk about working copies.

Thanks for any advice,

-- 
Groeten/Greetings,
Jeroen Coumans
www.jeroencoumans.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 10 13:36:26 2004

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.