Finally got a bit of time to catch up with this thread
in more detail...
On Fri, Jan 09, 2009 at 01:06:21PM -0500, 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.
Hmmm... this is not easy.
In 1.5, moving local modifications from one file to another
is essentially non-deterministic, because it depends on 'svn
update' to carry out operations in a certain order (add new
file before deleting old file).
Having non-deterministic behaviour in the code means we cannot
reliably write unit tests for it. (Which is something I do not
like at all, btw.)
One question I have is whether the act of flagging a tree
conflict somehow leads to the copy improvements to work
reliably, because the file is never removed from disk at
the old location. This is possible, but I don't know (yet)
whether this is a sound assumption to make.
> 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
This is what I'd expect from tree conflicts minus the
copy improvements made in 1.5.
> Or would we expect the local edits to alpha to be merged to
> alpha.moved resulting in a conflict there as well?
This is what I'd expect if tree conflicts happen to interact
with copy improvements in such a way that copy improvements
happen to be deterministic in this situation.
(When I write "copy improvements", I mean the act of applying
local edits made to the file at the move source path to the
file at the move target path.)
> >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:
I think we don't want alpha to be deleted from disk, ever.
It should at least be unversioned.
Or do you envision its content to live in alpha.moved.mine
after the update? I still think that might cause confusion,
because people might not realise that their local changes
to alpha have been preserved elsewhere.
> >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
Stefan
Received on 2009-01-11 23:42:34 CET