You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Chris Rose <ch...@messagingdirect.com> on 2008/01/13 22:50:25 UTC
Incorrect behaviour on wc copy when using checkout/update --depth
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.
Re: Incorrect behaviour on wc copy when using checkout/update --depth
Posted by Karl Fogel <kf...@red-bean.com>.
Chris Rose <ch...@messagingdirect.com> writes:
>> True, but our users have not been clamoring for that ability (as far
>> as I can tell).
>>
>> I'm not dead set against a --retain-depth option if we hear from
>> multiple users that they want it (and all want the same thing). But I
>> don't think we should add it before 1.5. The depth features are new,
>> we should see how people use them before adding more flags that we'll
>> have to maintain "forever" :-).
>>
>> -Karl
>
> That's a reasonable concern. I suppose that if I need it to do that
> I'll patch it myself and maintain it as an internal branch; I can
> propose the integration onto the trunk in a later revision if it looks
> A) solid and B) useful.
Thanks for being so understanding, Chris.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Incorrect behaviour on wc copy when using checkout/update --depth
Posted by Chris Rose <ch...@messagingdirect.com>.
Karl Fogel wrote:
> Chris Rose <ch...@messagingdirect.com> writes:
>> 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.
>
> True, but our users have not been clamoring for that ability (as far
> as I can tell).
>
> I'm not dead set against a --retain-depth option if we hear from
> multiple users that they want it (and all want the same thing). But I
> don't think we should add it before 1.5. The depth features are new,
> we should see how people use them before adding more flags that we'll
> have to maintain "forever" :-).
>
> -Karl
That's a reasonable concern. I suppose that if I need it to do that
I'll patch it myself and maintain it as an internal branch; I can
propose the integration onto the trunk in a later revision if it looks
A) solid and B) useful.
--
Chris Rose
Developer Planet Consulting Group
(780) 577-8433
crose@planetci.com
Re: Incorrect behaviour on wc copy when using checkout/update --depth
Posted by Karl Fogel <kf...@red-bean.com>.
Chris Rose <ch...@messagingdirect.com> writes:
> 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.
True, but our users have not been clamoring for that ability (as far
as I can tell).
I'm not dead set against a --retain-depth option if we hear from
multiple users that they want it (and all want the same thing). But I
don't think we should add it before 1.5. The depth features are new,
we should see how people use them before adding more flags that we'll
have to maintain "forever" :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Incorrect behaviour on wc copy when using checkout/update --depth
Posted by Chris Rose <ch...@messagingdirect.com>.
On 14-Jan-08, at 8:17 AM, C. Michael Pilato wrote:
> David Glasser wrote:
>> 2008/1/13 Chris Rose <ch...@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 <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On
> Demand
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Incorrect behaviour on wc copy when using checkout/update --depth
Posted by Chris Rose <ch...@messagingdirect.com>.
Well, I'd like to discuss what this should look like; I believe that
there are two parts to the problem, if I am to add a libsvn_client
enhancement to support this:
1) Copy/Move must retain the depth information in the working copy.
From what I can tell, this is already the case. Moreover, copy/move
must have the correct associations set for all files in the copy, not
just the top directory. I don't know if this is the case, and this is
pretty important to support the systematic add-with-history down the
whole tree that is required with this.
2) Commit must have the option of committing a copy/move operation by
walking the local tree and only transmitting the portions of the tree
that exist in the working copy instead of doing the clever thing and
simply performing a remote copy.
I propose a --retain-depth option to commit to support this change.
When this flag is enabled, we get #2, above.
The algorithm will be:
for each node:
if the node is not a container
commit a copy of the node
next node
if the node is a container and the node's depth is infinite:
commit a copy of the node
next node
if the node is a container and the depth is emtpy:
commit a copy of the node with no children
next node
if the node is a container and the depth is directory or files:
commit a copy of the node with no children
for each child of the node, re-invoke this algorithm
next node
I'm not 100% sure that case 3 is possible given the current API. If
it's not, then this change might be out of the range of possibilities
for me to do given my limited experience with the svn code. If it _is_
doable, then I have a reasonable degree of confidence that I can
accomplish this.
Opinions?
Chris Rose wrote:
>
>
> David Glasser wrote:
>> On Jan 14, 2008 10:17 AM, C. Michael Pilato <cm...@collab.net> wrote:
>>> 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.
>>
>> I was mostly sure before, but you've got me convinced.
>>
>> --dave
>>
>
> Well, suppose I was to implement support for my suggested --retain-depth
> option, to add this capability. Would such a patch be acceptable,
> assuming it works as advertised?
>
--
Chris Rose
Developer Planet Consulting Group
(780) 577-8433
crose@planetci.com
Re: Incorrect behaviour on wc copy when using checkout/update --depth
Posted by Chris Rose <ch...@messagingdirect.com>.
David Glasser wrote:
> On Jan 14, 2008 10:17 AM, C. Michael Pilato <cm...@collab.net> wrote:
>> 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.
>
> I was mostly sure before, but you've got me convinced.
>
> --dave
>
Well, suppose I was to implement support for my suggested --retain-depth
option, to add this capability. Would such a patch be acceptable,
assuming it works as advertised?
--
Chris Rose
Developer Planet Consulting Group
(780) 577-8433
crose@planetci.com
Re: Incorrect behaviour on wc copy when using checkout/update --depth
Posted by David Glasser <gl...@davidglasser.net>.
On Jan 14, 2008 10:17 AM, C. Michael Pilato <cm...@collab.net> wrote:
> 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.
I was mostly sure before, but you've got me convinced.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Incorrect behaviour on wc copy when using checkout/update --depth
Posted by "C. Michael Pilato" <cm...@collab.net>.
David Glasser wrote:
> 2008/1/13 Chris Rose <ch...@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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Incorrect behaviour on wc copy when using checkout/update --depth
Posted by David Glasser <gl...@davidglasser.net>.
2008/1/13 Chris Rose <ch...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org