Re: Is there a way to 'sparsify' a working copy, without starting over?

On Mon, Jun 13, 2016 at 3:39 AM, Branko Čibej <brane_at_apache.org> wrote:
> On 13.06.2016 01:24, Johan Corveleyn wrote:
>> I have a (full depth infinity) working copy:
>>
>> parent
>> \-- sub1
>> \-- sub2
>>
>> I'd like to make it sparse, throwing out sub2, so it becomes:
>>
>> parent (empty)
>> \-- sub1 (infinity)
>>
>> Is there a way to do that, without first making 'parent' entirely
>> empty (by executing 'svn up --set-depth empty parent')? Making
>> 'parent' depth=empty would also remove sub1 which I then have to
>> retrieve from the server again.
>>
>> Note: removing sub2 by running 'svn up --set-depth exclude
>> parent/sub2' is not the same (parent would still be depth=infinity, so
>> new subdirs could appear on subsequent updates).
>
> --set-depth empty on parent is the correct first step. The contents of
> parent/sub1 will still be in the pristine store, so you won't be
> fetching all that much data from the server.

Ah yes, I didn't think of that. Thanks for reminding me.

Unfortunately, there is still a bit of risk involved in doing this if
you have local modifications below sub1 (which you'd like to keep
around).

File modifications seem to be no problem (they are preserved, that
part of the tree is kept as a sparse piece of tree, with correct
metadata). So, say if sub1/path/file would be modified, after 'svn up
--set-depth empty parent' you'd end up with:

  parent (empty)
      \-- sub1 (empty)
             \-- path (empty)
                    \-- file (modified)

So after re-instating sub1 with 'svn up --set-depth infinity
parent/sub1' you'd get:

  parent (empty)
      \-- sub1 (infinity)
             \-- path (infinity)
                    \-- file (modified)
                    \-- ...

But if you have local moves, it seems the 'Delete' part of the move is
lost when updating to depth empty, and the move is broken (converted
into just the A+ of the "Add" part).

This looks like a bug in "update --set-depth" (losing information
about local deletes (potentially part of a move)).
Other than that, this technique seems to work fine.

-- 
Johan