subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Corveleyn <>
Subject Re: Parallel branches/tags/trunk directories
Date Mon, 15 Aug 2011 22:49:44 GMT
On Fri, Aug 12, 2011 at 3:12 AM, Mike Cepek <> wrote:
>> I'll bite...
>> Why do you need to checkout everything from the "proj" level of the
>> tree? If it is common to checkout from the project level of the tree,
>> how do you branch or tag if you have to branch and tag each and every
>> directory?
> Sorry, I missed this earlier reply.  You identify good issues, David, and I've raised
them.  I think it's one of those things where I can see the issues before others do, and
until the pain becomes theirs personally, there's no point in trying.
>> proj/trunk|tags|branches/*
> I've used that project layout in all my past projects with SVN, CVS, ... sccs (yes, way
back).  In this particular project, the sets of deploy/ directories will be managed separately
by another team.
> My attempt at anonymization unfortunately obfuscated the layout a bit.  I can see reasons
for a layout like this in our case:
> proj/common/trunk|tags|branches
> proj/top[1|2]/trunk|tags|branchesproj/deploy/common/trunk|tags|branches
> proj/deploy/top[1|2]/trunk|tags|branches/env[1-9]
> The codebase resides in the first trees, and runtime configuration (deploy) stuff in
the latter ones.  The top1/ and top2/ projects evolve independently, but share the common/
> I agree that SVN makes adjusting this pretty simple.  I hope we have that opportunity
before the concrete hardens too much more.  Thanks.

A bit late perhaps, but nevertheless: maybe you should take a look at
the script '' [1]. It can automate the building up of a
sparse working copy, based on a simple configuration file specifying
which part of the tree is needed. You could create such a config file
for your team, which allows anyone to quickly set up the required
sparse working copy (provided they have python, or can easily install

In your case the config file might look like this:

-------- 8< --------
Format: 1

-------- 8< --------

Of course this is still a 'static' solution, it doesn't determine the
'trunks' dynamically. But it those things/envs/... are relatively
stable, it could help. Otherwise, you'll have to put in some process
or procedure to keep the config file in sync with reality.



View raw message