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:39:12 CEST