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

Re: Parallel branches/tags/trunk directories

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: Thu, 11 Aug 2011 12:28:35 -0500

On 8/11/2011 12:07 PM, Mike Cepek wrote:
>
>> What version of the server are you running? I think if you use Sparse directories with a pre 1.6 server
>> the server sends all the files and the client just throws away what doesn't fit into your requested depth.
>
> Ah. Our server reports itself as 1.4.2. That probably explains why it took so long. I have no idea what the odds are of having our server upgraded (used by many other projects).

The likely reason for having one that old is that it was what was
included in a Red Hat or CentOS distribution and you haven't done a
system update recently (or it is older than the 5.x version). If it is
a 5.x, there are plenty of good reasons to update it, including bringing
subversion up to a usable 1.6.x.

>> That all said, I don't really see the benefit of having one working copy that you can update at once.
>
> As opposed to having 14 working copies that every developer has to manually maintain? Really? The layout in my OP is only part of this project. We really do have 14 separate branches/tags/trunks trees. This is a new project, so that number will probably go up over time.

Why can't you build your own unversioned top level tree and check out
the parts you want in the places they should be underneath it? A script
to do that shouldn't be any harder than loading the right pieces under a
sparse tree and you can jump around in the branches with svn switch. Or
build a versioned tree that uses externals to pull what you want. All
you lose is the ability to do a single top-level commit when you have
changes in multiple components.

-- 
   Les Mikesell
    lesmikesell_at_gmail.com
Received on 2011-08-11 19:35:49 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.