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

Re: Sparse Directories and --set-depth

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Tue, 16 Sep 2008 15:51:44 -0400

Wow.

I'm sorry that I don't have time to evaluate your description in detail,
but glancing over it, I think a combination of depths (some
--depth=immediates, some --depth=empty), with checkouts managed by a
script so your developers don't have to remember it, would work.

What you really want are "client specs", but Subversion doesn't have
those yet. See http://svn.haxx.se/dev/archive-2006-07/0624.shtml .

-Karl

Rush Manbert <rush_at_manbert.com> writes:
> On Sep 16, 2008, at 10:28 AM, Karl Fogel wrote:
>
>> Rush Manbert <rush_at_manbert.com> writes:
>>> Another sparse directories question.
>>>
>>> There appears to be no way to use the --set-depth argument to set the
>>> depth metadata for a directory to "infinity" without also setting the
>>> depth metadata for all its immediate child directories to "infinity".
>>>
>>> What I want to do is set the topmost directory to infinity while not
>>> changing the depth metadata on its child directories.
>>>
>>> Is this really not possible?
>>
>> It's not possible, because it doesn't make sense, according to
>> Subversion's idea of depth. If a directory D is at depth 'infinity',
>> then everything under it is too; that's just the way depth works.
>>
>> Could you describe the actual behavior you want, without using any of
>> Subversion's depth words? Then we can say whether or not the precise
>> arrangement you need is possible using Subversion depths. (It may be
>> that you can get something close, but not quite exactly what you were
>> looking for.)
>>
>> My guess is that you'll want the top-level directory to be at depth
>> 'immediates', and then you'll need to set each of various
>> subdirectories
>> to the particular depth appropriate for that subdirectory.
>>
>> -Karl
>
> Hi Karl,
>
> Thanks for the reply. I will try to describe what I want to accomplish.
>
> My repository's trunk looks like this:
> trunk
> uber
> projectA
> subsys1
> myStuff
> thirdPartyLibs
> installedMac
> libA.a
> libB.a
> installedWin
> libA.lib
> libB.lib
> source
> libA
> libB
> scripts
> file1
> file2
> dirA
> subsys2
> subsys3
> projectB
> .
> .
> .
>
> We have an "uber" directory that contains our different projects.
>
> Each project contains a number of subsystems, shown above for projectA
> as "subsys1", "subsys2", and "subsys3".
>
> Within each subsystem, at various levels, there is platform-specific
> content, shown here as "installedMac" and "installedWin". Sometimes
> the immediate children of these directories are only directories.
> Sometimes they are only files, and sometimes they are a mix of files
> and subdirectories. We tend to have developers who specialize in
> particular platforms, so they just want to check out the content that
> is applicable to their platform. (Built libraries for each platform
> constitute about 2-3 Gigabytes) Additionally, no one usually wants to
> check out the library sources, because it's about a Gigabyte, and
> contains 37000 files (almost all of that is Boost sources). You only
> want that if you need to debug and step into the library source.
>
> Different developers are interested in different subsets of the
> available subsystems. For instance, the top level subsystems in one of
> our projects are "client", "common", "firmware", and "server". The
> server and client code is dependent on the common code, but the
> firmware subsystem is independent, so some people want to check out
> "client" and "common", others want "server" and "common", others just
> want "firmware", and some want all of them.
>
> Given all of this, a very typical checkout scenario is this:
> * I want to check out projectA on the Mac platform.
> * I want the contents of subsys1 and subsys2, but not the contents of
> subsys3.
> However, I want an empty subsys3 directory to exist in my working
> copy, and if anyone adds a new subsystem to projectA, I want to see
> its top level directory appear when I do a svn update.
> * Within subsys1, I need "myStuff" to be fully populated, because it
> contains nothing platform-specific. I need thirdPartyLibs/installedMac
> to be fully populated. I really don't want to see thirdPartyLibs/
> installedWin, but I am okay with having it be present and empty. I
> want thirdPartyLibs/sources to be present and empty, and I want
> thirdPartyLibs/scripts to be present and empty.
> * On any subsequent svn update, I want the contents of myStuff and
> thirdPartyLibs/installedMac to reflect whatever changes have happened
> in the repository. I guess there could be some debate about what I
> want to have happen if someone adds a new immediate child to
> thirdPartyLibs. If it's a file, it should appear. If it's a directory,
> I believe that I want it to appear and be fully populated. (I think
> this makes me want thirdPartyLibs to have depth=infinity while some of
> his children have depth=empty) Maybe I need to be argued out of that,
> or shown why it's desirable to have it appear and be empty. :-)
>
> After the checkout completes, I want my working copy to look like this:
>
> workingCopyTop
> subsys1
> myStuff
> full content from repository
> thirdPartyLibs
> installedMac
> libA.a
> libB.a
> installedWin
> source
> scripts
> subsys2
> full content from repository
> subsys3
>
> I think this basically describes what I want to do. There are
> obviously many variations on the checkout scenario, and my real
> repository is more complicated and has platform-specific content in a
> number of different places within each subsystem.
>
> I should also mention that, because of the repository complexity,
> there is no way that my developers can do these checkouts manually. I
> need to be able to automate it with scripts. I also have the
> requirement that I must be able to do a plain "svn co" of trunk/uber/
> projectA into a working copy on any platform and be able to do a
> successful platform-specific build from that checkout.
>
> - Rush

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-16 21:52:09 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.