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

On Tue, Jun 14, 2016 at 10:04 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> 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?

Similarly, a plain Delete is also lost when "emptying" the working
copy. I think the "scheduled delete" should simply stay (keep all
local changes, whether they are text or tree changes, when making the
working copy more sparse).

[[[
C:\svntest>svn co file:///c:/svntest/r wc2
A wc2\iota
Checked out revision 1.

C:\svntest>cd wc2

C:\svntest\wc2>svn rm iota
D iota

C:\svntest\wc2>svn st
D iota

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

C:\svntest\wc2>svn st

]]]

-- 
Johan