Re: 1.6 blocker? copy operation during update fails

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?

>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

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

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

Paul
Received on 2009-01-09 19:06:43 CET