Re: 1.6 blocker? copy operation during update fails

Paul Burba wrote:
> On Thu, Jan 8, 2009 at 10:27 PM, Neels J Hofmeyr <neels_at_elego.de> wrote:
>> Hi guys,
>>
>> I've been looking at this, but in the end am back to square one. Anyway,
>> I've established that r34158 entirely changes the code path for this
>> scenario (issue #3354), and that's ok. :P
>
> I added a new XFailing update test in r35125 to cover issue #3354.
>
> I'm not entirely sure the expectations are correct however. Should we
> be left with 'alpha' as scheduled for addition but conflicted and
> alpha.moved added normally?

You mean 'alpha' scheduled for deletion, right?

>
>> svn st update_tests-52.other\A\B\E
> A + C update_tests-52.other\A\B\E\alpha
> > local edit, incoming delete upon update

That would be D.

>
> Or would we expect the local edits to alpha to be merged to
> alpha.moved resulting in a conflict there as well?
>
>> svn st update_tests-52.other
> ? update_tests-52.other\A\B\E\alpha.moved.r2
> ? update_tests-52.other\A\B\E\alpha.moved.r3
> ? update_tests-52.other\A\B\E\alpha.moved.mine
> A + C update_tests-52.other\A\B\E\alpha
> > local edit, incoming delete upon update
> C update_tests-52.other\A\B\E\alpha.moved

A text conflict on alpha.moved wouldn't do.

>
> Or should we just delete alpha and attempt to merge its local changes
> to alpha.moved and have a conflict there only:
>
>> svn st update_tests-52.other
> ? update_tests-52.other\A\B\E\alpha.moved.r2
> ? update_tests-52.other\A\B\E\alpha.moved.r3
> ? update_tests-52.other\A\B\E\alpha.moved.mine
> C update_tests-52.other\A\B\E\alpha.moved

Something like this, eventually, but definitely not a text conflict, but a
tree conflict instead.

The previous behaviour I think was like this:

$ svn up
   C update_tests-52.other\A\B\E\alpha
A update_tests-52.other\A\B\E\alpha.moved

$ svn st
D + C update_tests-52.other\A\B\E\alpha
> local edit, incoming delete upon update
<Nothing about alpha.moved. It has been added and is up-to-date.>

alpha is scheduled for deletion but still hangs around.
I think for now, we'd go back to that behaviour.

[drifting into a fundamental discussion...]

But, IIRC, we are on the long run aiming at behaviour like this:

- the update is actually carried out, but there is a conflict on the updated
file(s). Conflicted files are brought to the new base.

- any local mods on deleted files are kept in temporary files.

- resolving the conflict is able to bring back mine, accept theirs, or to
merge the two, ideally giving independent choice for both content and file
name. All this without contacting the repository again.

The one from above still makes sense, with the only difference being that
'alpha' would already be deleted:

$ svn up
D C update_tests-52.other\A\B\E\alpha
A update_tests-52.other\A\B\E\alpha.moved

$ svn st
? C update_tests-52.other\A\B\E\alpha
> local edit, incoming delete upon update

I am thinking though that it would be good to also mark alpha.moved as
conflicted. In above example, I would still be able to commit alpha.moved
without being blocked by a conflict. The code seems to be aware of them
being part of a `move' anyway (when did that happen).
But this one has a problem at the bottom:

$ svn up
D C update_tests-52.other\A\B\E\alpha
A C update_tests-52.other\A\B\E\alpha.moved

$ svn st
? C update_tests-52.other\A\B\E\alpha
> local edit, incoming delete upon update
      C update_tests-52.other\A\B\E\alpha.moved
> ### what to say here?? ### upon update

$ svn info update_tests-52.other\A\B\E\alpha.moved
...
Tree-conflict:
  ### what to say here?? ###

Am I making sense?
~Neels

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1014564