Stefan and I just had a short debugging session. I think in merge_file()
it's getting confused between the file that had modifications ('alpha')
and the target where it's trying to put them ('alpha.moved') and making
wrong if/else decisions, ending up calling
svn_wc__merge_internal(target="alpha.moved") when it shouldn't.
I've added "###" comments about this into that function. That's all I
can do today. Anyone else?
Putting the issue number in the Subject line so I can find the thread
again.
- Julian
Stefan Sperling wrote:
> 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
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1022553
Received on 2009-01-13 18:54:16 CET