David Glasser wrote:
> 2008/1/13 Chris Rose <chris.rose_at_messagingdirect.com>:
>> The short description is this:
>>
>> If I check out a working copy without taking all of its children (say,
>> with depth=empty, or depth=files etc...) then when I copy it into
>> another part of the working copy that restriction should propagate:
>>
>> % svn co --depth=empty $url/trunk/foo
>>
>> % svn co $url/tags
>>
>> % svn cp foo tags/foo_tagged
>>
>> % ls tags/foo_tagged
>> <nothing>
>>
>> % svn ci -m "Tagged an empty copy of 'foo'" tags
>>
>> % svn co $url/tags/foo_tagged
>>
>> % ls foo_tagged
>> <everything that was in foo on the trunk>
>>
>> Attached is a script that demonstrates the issue in detail. It
>> requires svn 1.5, because --depth is a new thing :)
>>
>> I contend that checking in a working copy that does not have files,
>> and then checking the same URL out to find out that it does have files
>> violates the principle of least surprise. However, it would probably
>> be enough to provide an option to preserve checkout depth on copy.
>
> Hmm.
>
> The Subversion 1.5 depth feature is a purely working-copy-local
> concept. The server does not store a "recommended depth" for
> directories. So it would certainly not be correct to have the script
> you show end up checking out a non-infinite depth wc.
>
> The key questions here is, if you do a wc-wc (or wc-repo) copy of a
> non-infinite-depth wc path, should the commit just be
> "add_directory(copyfrom=url-of-wc-directory)", or should it also fake
> up some delete_entry calls to make the target of the copy "look like"
> the wc version?
>
> I'm not sure, but I'm leaning towards the current behavior being correct.
I think the copies should "go deep" even if their working copy
representations are not. This would greatly facilitate the reorganization
of large directories (tags, branches, etc.) without having to have those
things fleshed out on local disk in full.
If you want to copy a trimmed directory and have the result be trimmed, then
delete the items you don't want and copy that. You don't have to commit the
original deletions -- those can be reverted post-copy.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-01-14 16:18:35 CET