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

On Mon, Jun 13, 2016 at 10:52 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Johan Corveleyn wrote on Mon, Jun 13, 2016 at 10:04:13 +0200:
>> 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.
>
> Is the bug specific to --set-depth? It sounds like a delete-delete tree
> conflict, in which case, I would expect the following scenario to
> trigger the same behaviour:
>
> # greek tree
> svnadmin create r
> svn co -q file://$PWD/r wc
> cd wc
> touch iota
> svn add -q iota
> svn ci -q -m r1
> svn up -q
> # scenario:
> svn rm -q -m r2 ^/iota
> svn mv -q iota kappa
> svn up
>
> Sorry, I can't test this right now...

No it doesn't trigger this behaviour. This gives a delete-delete tree
conflict, as expected.

But watch this:

[[[
C:\svntest>svnadmin create r

C:\svntest>svn co -q file:///c:/svntest/r wc

C:\svntest>cd wc

C:\svntest\wc>touch iota

C:\svntest\wc>svn add -q iota

C:\svntest\wc>svn ci -q -m r1

C:\svntest\wc>svn up -q

C:\svntest\wc>svn mv iota kappa
A kappa
D iota

C:\svntest\wc>svn st
D iota
> moved to kappa
A + kappa
> moved from iota

C:\svntest\wc>svn up --set-depth empty
D iota
Updating '.':
Updated to revision 1.

C:\svntest\wc>svn st
A + kappa
]]]

Oops. Delete information is lost, and with it also the move information.

I don't think this should raise a tree conflict (just like when iota
is 'M', and you execute 'svn up --set-depth empty', the modified iota
is just left there as a part of the sparse tree -- no delete-edit
conflict is raised). So I think it should just leave the 'D's (and
move information) there. The "emptying" seems to be optional, IIUC the
intention is that anything that's modified in some way should be left
alone (which is cool when sparsifying).

The above scenario looks like a bug, no?

-- 
Johan