On 14-Jan-08, at 8:17 AM, C. Michael Pilato wrote:
> 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.
This is true as far as it goes, but it's certainly not clear that the
results are what would or should occur. The actions leading up to the
copy imply an expectation of selective copying, and it would be useful
if the other svn client operations honoured that.
As you say, there's a workaround, but I'd rather see the client
support it directly. It might even be easy, although I don't know for
sure. Perhaps, as suggested, add a --retain-depth flag for copy/
move? It would make the set of client operations more complex -- you
would have to walk the tree and build up the copy on the server from
the set of entities that are on disk -- but it would reintroduce a CVS
ability: the ability to tag a subset of a directory.
>
> --
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Distributed Development On
> Demand
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-14 16:59:04 CET