Skipping considered harmful (was Re: Tree conflicts - problem handling when local directory is deleted)

Quoting Julian Foad <julianfoad_at_btopenworld.com>:

> On Thu, 2009-01-22 at 11:20 -0500, Mark Phippard wrote:
>> On Thu, Jan 22, 2009 at 11:07 AM, Stephen Butler <sbutler_at_elego.de> wrote:
>> > Quoting Mark Phippard <mphippard_at_collab.net>:
>> >
>> >> On Thu, Jan 22, 2009 at 9:56 AM, Julian Foad
>> <julianfoad_at_btopenworld.com>
>> >> wrote:
>> >>>
>> >>> FYI I'm just about to look at this.
>> >>
>> >> I added an svn info to the script to look at the tree conflict. The
>> >> problem is that after running update the local revision in the WC for
>> >> the folder is 1 when it should have been updated to 2 by the update
>> >> command. So this is why it is out of date when you try to commit.
>> >> When the tree conflict was created it should have still allowed the WC
>> >> revision to be updated.
>> >
>> > Turning off the skipping of tree conflict victims is pretty
>> > straightforward, at least for this use case (#1 in
>> > notes/tree-conflicts/detection.txt).
>> >
>> > What should we do if the user runs update again without resolving the
>> > existing tree conflict first? Skipping is not an option.
>>
>> I've never really grokked why we'd skip updating something, but I am
>> sure there are some reasons.
>
> In text conflicts, it's hard to imagine how we could do better than
> skip, so we just skip. In tree conflicts, likewise, except now I think
> about it it might not be too hard to design how to "compose" two tree
> conflicts together... at least in some cases, such as when one of the
> conflicts involves deleting the node.
>
>> Clearly the current situation is worse
>> though. You cannot commit, because you are out of date, and if you do
>> update again after resolving the tree conflict all it does is create
>> it again.
>
> 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.

>
> Seems to work for me.
>
> I'm not saying that's good, just possible.
>
> - Julian

So, automating this workaround, and doing similar workarounds for other
use cases, we'd end up doing somethin useful in almost all cases.

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.

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?

Steve

UC1 "local delete, incoming edit on update"

   delete -> delete (rev=rNEW;
                         base at rNEW;
                         rNEW merged into working)

UC2 "local edit, incoming delete on update"

   normal -> add w/hist (rev=r0;
                             base at rOLD;
                            copyfrom=rOLD)

   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"

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