Julian Foad wrote:
> On Thu, 2009-01-22 at 11:30 -0500, Mark Phippard wrote:
> > On Thu, Jan 22, 2009 at 11:28 AM, Julian Foad
> > <julianfoad_at_btopenworld.com> wrote:
> > > On Thu, 2009-01-22 at 17:07 +0100, Stephen Butler wrote:
> > >> Turning off the skipping of tree conflict victims is pretty
> > >> straightforward, at least for this use case (#1 in
> > >> notes/tree-conflicts/detection.txt).
> > >
> > > Is it? "Turning off skipping" means "designing and implementing some
> > > behaviour other than skipping". The local node is scheduled for
> > > deletion. The incoming change is to modify it. I assume the existing
> > > "update" code would not handle this case already.
> >
> > That is exactly what 1.5.5 does. The base is updated, you can revert
> > etc. That said, I did not test this exhaustively, but that is what it
> > seemed to do to me.
>
> Oh, OK. That would make it really easy to implement the way we want it.
> Great. I'll have a go if Stephen doesn't beat me to it.
(My previous attempt at this reply had "==" instead of "!=", but was not
anywhere near right anyway.)
Attached is a patch towards solving this.
Here's where I've got to:
I separated out the different kinds of checks at the top of
open_directory() in subversion/libsvn_wc/update_editor.c. That change is
fine by itself.
I made the "skip" part conditional on this node not being scheduled for
deletion. That means it follows through to do the update, which we
believe handles the situation as desired, except perhaps for recursive
behaviour.
PROBLEMS:
- multiple notifications
- recursive behaviour may not be right
- test failures not investigated
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1045039
Received on 2009-01-23 17:15:31 CET