Re: Incorrect behaviour on wc copy when using checkout/update --depth

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 <cmpilato_at_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_at_planetci.com