Quoting Julian Foad <julianfoad_at_btopenworld.com>:
[...]
>
> 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.
Hold that thought! For now, please read my comments below in the
spirit of "not skipping". As a thought experiment, to see if
avoiding the skipping makes the design simpler.
I'm worried that skipping old tree conflicts will put the user on
the merry-go-round (can't commit, can't update; resolve && update
recreates the tree conflict).
> > 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.
I want to reduce the number of situations in which we create tree
conflicts. I suppose restoring the 1.5 behavior (raising an error)
is acceptable for now, to get us off the hot seat for releasing
1.6.0.
>
> > 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.
Via 'svn status', the user can see all the tree conflicts and their
reasons. If a tree conflict victim is marked "local delete, ..." but
is now schedule-normal, then obviously (to me, anyway) the tree conflict
is old news and the user could resolve it immediately.
It seems reasonable to leave the old tree conflict in place until
explicitly resolved, and to rely on the user to notice that the
old conflict still exists. At the latest, they'll notice it upon
trying to commit!
In the future we could make it friendlier. I suppose we could add a
warning during update, to say that we encountered an existing tree
conflict. Or we could automatically resolve the existing t.c. if the
reason for it no longer holds.
> > 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?
If the user reverts the local delete, then the second update wouldn't
find a tree conflict there. It'd continue as normal, possibly halting
with an error due to an insurmountable obstruction, or raising a new
conflict on a child or grandchild of the earlier victim.
Here's an imaginary transcript of reverting a local deletion, then
encountering new conflicts inside the old victim:
$ svn status
D C mydir
> local delete, incoming edit upon update
D mydir/alpha
D mydir/beta
$ svn add mydir # revert the deletion
$ svn up
D C mydir/alpha
C mydir/beta # here's the incoming edit
Updated to revision 999.
Summary of conflicts:
Text conflicts: 1
Tree conflicts: 2
$ svn status
C mydir
> local delete, incoming edit upon update
M C mydir/alpha
> local edit, incoming delete upon update
C mydir/beta
>
> "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).
You're right, there's no merging or text/prop conflicts for
schedule-delete items. I've just done some experiments with SVN 1.5.5
to check the current behavior. The incoming (rNEW) text and prop
changes are written in the working copy, overwriting whatever "working
version" may remain.
Note that if the user deleted the tree with --keep-local, then the
whole tree remains visible in the working copy.
>
> 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.
Absolutely. I forgot to mention that this is the only line of this
table that is already implemented (for the record, in the
issue-3334-dirs branch).
>
>
> > 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?
By "edit" we really mean "tinkered with", don't we? ;-)
If the victim is a file, then only the "normal" schedule is applicable
(otherwise it'd be a different use case).
If the victim is a directory tree, then we should treat each of its
nodes according to the node's own schedule.
Regards,
Steve
> > > 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!
>
>
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Received on 2009-01-28 21:40:12 CET