You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Dave Andreas <Da...@silabs.com> on 2011/01/28 16:35:45 UTC
sparse working directories and externals
I've encountered a few anomalies regarding the sparse workaareas and externals. I can construct a sparse workarea using either a top down approach or a bottoms up approach as shown in the following examples
Top down:
$ svn co -depth immediates <URL> modules
A modules
A modules/module1
A modules/module2
$ svn update -set-depth immediates modules/*
A modules/module1/subdir1
A modules/module1/subdir2
A modules/module2/subdir1
A modules/module2/subdir2
$svn update -set-depth infinity modules/*/subdir1
A modules/module1/subdir1/file1
A modules/module2/subdir1/file3
Bottoms up:
$svn co <URL> modules
A modules
A modules/module1
A modules/module1/subdir1
A modules/module1/subdir1/file1
A modules/module2/subdir2
A modules/module1/subdir2/file2
A modules/module2
A moduels/module2/subdir1
A modules/module2/subdir1/file3
A modules/module2/subdir2
A modules/module2/subdir2/file4
A modules/external1/subdir1
A modules/external1/subdir1/file5
A modules/external1/subdir2/
A modules/external1/subdir2/file6
$svn update -set-depth empty modules/*/subdir2
D modules/module1/subdir2/file2
D modules/module2/subdir2/file4
D modules/external1/subdir2/file6
If it weren't for the external, the result is the same. Unfortunately the initial checkout of an external appears to be an all or nothing scenario requiring a depth of infinity.
The disadvantage of a bottoms up approach is that I'm checking out everything from the repository into the workarea and them pruning it back. In my actual case, I'm dealing with 10's of thousands of file and this process can take nearly 3 hours.
The ideal solution would be a top down approach that handled externals identically to modules from the local repository.
Any suggestions?
Dave Andreas
This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication.
Thank you.
RE: sparse working directories and externals
Posted by Dave Andreas <Da...@silabs.com>.
Johan,
Thanks for the reply. I looked at the two issues being tracked and they summary my problem fairly well.
Dave Andreas
-----Original Message-----
From: Johan Corveleyn [mailto:jcorvel@gmail.com]
Sent: Saturday, January 29, 2011 3:48 AM
To: Dave Andreas
Cc: users@subversion.apache.org
Subject: Re: sparse working directories and externals
On Fri, Jan 28, 2011 at 4:35 PM, Dave Andreas <Da...@silabs.com> wrote:
> I've encountered a few anomalies regarding the sparse workaareas and
> externals. I can construct a sparse workarea using either a top down
> approach or a bottoms up approach as shown in the following examples
>
> Top down:
>
> $ svn co -depth immediates <URL> modules
>
> A modules
> A modules/module1
> A modules/module2
> $ svn update -set-depth immediates modules/*
> A modules/module1/subdir1
> A modules/module1/subdir2
> A modules/module2/subdir1
> A modules/module2/subdir2
>
> $svn update -set-depth infinity modules/*/subdir1
>
> A modules/module1/subdir1/file1
> A modules/module2/subdir1/file3
>
>
> Bottoms up:
>
> $svn co <URL> modules
>
> A modules
> A modules/module1
> A modules/module1/subdir1
> A modules/module1/subdir1/file1
> A modules/module2/subdir2
> A modules/module1/subdir2/file2
> A modules/module2
> A moduels/module2/subdir1
> A modules/module2/subdir1/file3
> A modules/module2/subdir2
> A modules/module2/subdir2/file4
> A modules/external1/subdir1
> A modules/external1/subdir1/file5
> A modules/external1/subdir2/
> A modules/external1/subdir2/file6
>
> $svn update -set-depth empty modules/*/subdir2
>
> D modules/module1/subdir2/file2
> D modules/module2/subdir2/file4
> D modules/external1/subdir2/file6
>
>
> If it weren't for the external, the result is the same. Unfortunately the
> initial checkout of an external appears to be an all or nothing scenario
> requiring a depth of infinity.
>
> The disadvantage of a bottoms up approach is that I'm checking out
> everything from the repository into the workarea and them pruning it back.
> In my actual case, I'm dealing with 10's of thousands of file and this
> process can take nearly 3 hours.
>
> The ideal solution would be a top down approach that handled externals
> identically to modules from the local repository.
>
> Any suggestions?
If I understand correctly, the problem is really at the start of your
explanation, in that:
> Top down:
>
> $ svn co -depth immediates <URL> modules
>
> A modules
> A modules/module1
> A modules/module2
doesn't checkout modules/external1. If that would be the case, it
would probably pan out the way you want, wouldn't it?
I think this is issue #3311:
http://subversion.tigris.org/issues/show_bug.cgi?id=3311 (externals
are not created unless depth=infinity)
I don't know an easy workaround. After your first step (checkout with
depth=immediates), can you "manually" pull in the externals with eg.
"svn update --set-depth=infinity external1"? In that case, maybe you
could script something, using the output of "svn propget
svn:externals" right after the "co --depth=immediates"? That would
still pull in too much of the externals themselves, but maybe it makes
it already a little more manageable ...
Unfortunately, there is no way to limit the depth of pulling in the
external itself, because of another issue:
http://subversion.tigris.org/issues/show_bug.cgi?id=3216 (externals
with --depth)
Cheers,
--
Johan
This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication.
Thank you.
Re: sparse working directories and externals
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Jan 28, 2011 at 4:35 PM, Dave Andreas <Da...@silabs.com> wrote:
> I’ve encountered a few anomalies regarding the sparse workaareas and
> externals. I can construct a sparse workarea using either a top down
> approach or a bottoms up approach as shown in the following examples
>
> Top down:
>
> $ svn co –depth immediates <URL> modules
>
> A modules
> A modules/module1
> A modules/module2
> $ svn update –set-depth immediates modules/*
> A modules/module1/subdir1
> A modules/module1/subdir2
> A modules/module2/subdir1
> A modules/module2/subdir2
>
> $svn update –set-depth infinity modules/*/subdir1
>
> A modules/module1/subdir1/file1
> A modules/module2/subdir1/file3
>
>
> Bottoms up:
>
> $svn co <URL> modules
>
> A modules
> A modules/module1
> A modules/module1/subdir1
> A modules/module1/subdir1/file1
> A modules/module2/subdir2
> A modules/module1/subdir2/file2
> A modules/module2
> A moduels/module2/subdir1
> A modules/module2/subdir1/file3
> A modules/module2/subdir2
> A modules/module2/subdir2/file4
> A modules/external1/subdir1
> A modules/external1/subdir1/file5
> A modules/external1/subdir2/
> A modules/external1/subdir2/file6
>
> $svn update –set-depth empty modules/*/subdir2
>
> D modules/module1/subdir2/file2
> D modules/module2/subdir2/file4
> D modules/external1/subdir2/file6
>
>
> If it weren’t for the external, the result is the same. Unfortunately the
> initial checkout of an external appears to be an all or nothing scenario
> requiring a depth of infinity.
>
> The disadvantage of a bottoms up approach is that I’m checking out
> everything from the repository into the workarea and them pruning it back.
> In my actual case, I’m dealing with 10’s of thousands of file and this
> process can take nearly 3 hours.
>
> The ideal solution would be a top down approach that handled externals
> identically to modules from the local repository.
>
> Any suggestions?
If I understand correctly, the problem is really at the start of your
explanation, in that:
> Top down:
>
> $ svn co –depth immediates <URL> modules
>
> A modules
> A modules/module1
> A modules/module2
doesn't checkout modules/external1. If that would be the case, it
would probably pan out the way you want, wouldn't it?
I think this is issue #3311:
http://subversion.tigris.org/issues/show_bug.cgi?id=3311 (externals
are not created unless depth=infinity)
I don't know an easy workaround. After your first step (checkout with
depth=immediates), can you "manually" pull in the externals with eg.
"svn update --set-depth=infinity external1"? In that case, maybe you
could script something, using the output of "svn propget
svn:externals" right after the "co --depth=immediates"? That would
still pull in too much of the externals themselves, but maybe it makes
it already a little more manageable ...
Unfortunately, there is no way to limit the depth of pulling in the
external itself, because of another issue:
http://subversion.tigris.org/issues/show_bug.cgi?id=3216 (externals
with --depth)
Cheers,
--
Johan