Stephen,
In an email an hour before this one, you explained why "skipping"
interferes with being able to interrupt and then continue an update.
Your comments were really helpful. Thanks.
Is there any way in which just dealing with freshly-raised tree
conflicts hurts our ability to make a future version deal better with
old tree conflicts? I'm not seeing any such harm, so I'm just trying to
deal with fresh conflicts.
On old conflicts, for now, I think it is acceptable to skip. I think we
have always skipped any updating of a text-conflicted file, and this is
analogous to that.
Stephen Butler wrote:
> Quoting Julian Foad <julianfoad_at_btopenworld.com>:
> > Note that the work-around is (should be) to mark as resolved, revert the
> > schedule-delete, update, then re-schedule the delete:
> >
> > svn resolved wc2/A/B/E
> > svn revert -R wc2/A/B/E
> > svn up wc2
> > svn delete wc2/A/B/E
>
> I believe the update would get rid of A/B/E completely (perhaps leaving
> some unversioned local mods), so the final delete is not needed. See
> UC3 below.
As Mark pointed out, that would apply to a different use case.
> So, automating this workaround, and doing similar workarounds for other
> use cases, we'd end up doing somethin useful in almost all cases.
Yes, indeed.
> In the following table, X -> Y means "in the given use case, an item
> with schedule X will be transformed to schedule Y". rOLD is the
> item's old BASE revision, "base" is the base text and/or props, rNEW
> is the target revision of the update, "gone" means "the item and
> its metadata no longer exist, or the item is now unversioned", and
> "SKIP!" means to skip the item and its descendants.
>
> We'd also revert our change to the dir-prop-conflict handling, to
> re-enable updating inside a dir that has a prop conflict. We made
> that change just for consistency's sake.
>
> If update runs into a text or property conflict, it should skip
> the item. Or rather stop with an error? Then the user could
> 'svn resolve --accept=mine -R .' before updating again, so that
> those conflicts are up to date. Just trying to go the extra mile
> to avoid skipping.
I haven't got the capacity to redesign or even think about new behaviour
for non-tree conflicts right now.
> As you can see, there's only one skip remaining in update. Can anyone
> see a simple workaround for it? Or point out any other weak spots?
In this scheme, we are expecting to deal with a subsequent update to a
node on which a previous update caused a tree conflict that has not yet
been resolved. We will often get situations where the "action" (incoming
change) and the "reason" (schedule) in the update that is currently
running are not the same as the action and reason recorded in the
pre-existing tree conflict. For example, if an edit caused a tree
conflict (on a schedule-delete node), the new action on this subsequent
update is perhaps a delete. The "reason" can be different because the
user has had the opportunity to change the scheduling of the node.
Because of this, we have to be very clear whether we're talking about
the action/reason of the pre-existing conflict, or of the current
update. And we have to say what we're doing when they differ.
> Steve
>
>
> UC1 "local delete, incoming edit on update"
>
> delete -> delete (rev=rNEW;
> base at rNEW;
> rNEW merged into working)
This, "delete", is the expected schedule of any node that has a UC1 tree
conflict, and of any node inside such, if the user has not tinkered with
it.
What incoming change are we talking about as the current update
operation here? "edit", I assume. What about other possible incoming
changes that could happen to a node that was once marked with such a
tree conflict and has been further updated but not yet marked as
resolved?
"rNEW merged into working" is inapplicable, because if the schedule is
"delete" the working version is nothing (except, if it's a directory, a
skeleton of directories whose base metadata should be updated by this
definition recursively).
What do we do with the other schedules that may be found if the user has
tinkered since the conflict was raised?
> UC2 "local edit, incoming delete on update"
>
> normal -> add w/hist (rev=r0;
> base at rOLD;
> copyfrom=rOLD)
Same concerns as for UC1 above.
Issue #3334 is doing this for the case when the tree conflict is freshly
raised.
> add -> add w/hist (rev=r0;
> base at rOLD;
> copyfrom=rOLD)
>
> add w/hist -> add w/hist (rev=r0;
> base at rOLD;
> copyfrom= <no change!>)
>
> delete -> "gone"
These schedules can occur if the node has been tinkered with ... or are
you thinking about nodes inside a sub-tree that has a UC2 tree conflict
on its root?
...
- Julian
>
> UC3 "local delete, incoming delete on update"
>
> delete -> "gone"
>
>
> "local add, incoming add on update"
>
> add -> normal (rev=rNEW;
> base at rNEW;
> rNEW merged into working)
>
> add w/hist -> SKIP!
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1058193
Received on 2009-01-27 10:26:58 CET