On Tue, Jun 14, 2016 at 10:04 PM, Johan Corveleyn <jcor...@gmail.com> wrote: > On Mon, Jun 13, 2016 at 10:52 AM, Daniel Shahaf <d...@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
