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.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
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 06:33:02 CET