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

RE: sparse working directories and externals

From: Dave Andreas <Dave.Andreas_at_silabs.com>
Date: Tue, 1 Feb 2011 17:50:03 -0600

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_at_gmail.com]
Sent: Saturday, January 29, 2011 3:48 AM
To: Dave Andreas
Cc: users_at_subversion.apache.org
Subject: Re: sparse working directories and externals

On Fri, Jan 28, 2011 at 4:35 PM, Dave Andreas <Dave.Andreas_at_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.

Received on 2011-02-02 00:50:49 CET

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.