Re: Tree conflict merry-go-round on update/switch

On Tue, Nov 25, 2008 at 05:55:14PM +0100, Stephen Butler wrote:
> Hi tree conflict fans,
>
> I had another look at Mark Phippard's experiment with creating
> a tree conflict during update (local edit, incoming delete,
> aka use case 2). That's a tricky one to recover from.
>
> Mark's original mail is here:
>
> <http://svn.haxx.se/dev/archive-2008-10/1090.shtml>
>
> If we skip the update of the victim, to be consistent with
> other tree conflicts, then the user has to resolve the conflict
> and update again before (optionally) re-adding the victim and
> committing the local changes.

Attached is a self-contained reproduction script.

> I fixed some of the problems that Mark noticed, but not all.
> There is a blocker in that the "update again" step creates a
> fresh tree conflict. Doh!

Isn't this circular dependency a side-effect of the way the
issue was solved in the first place (skipping updates of text
bases IIRC)?

Maybe that approach was wrong and we need another solution
which does not require preventing update from updating text
bases?

> An obvious solution is to record the tree conflict as resolved
> with regard to the incoming version. At a minimum, we need to
> record the incoming svn_wc_conflict_version_t; if an update or
> switch to the same URL_at_REV occurs, it will remove the resolved-
> version data and not create a tree conflict. An update/switch
> to a different URL_at_REV would create a new tree conflict.
>
> An alternative design is to add a boolean "resolved" field to
> the existing svn_wc_conflict_description_t. The resolve[d]
> commands would leave the tree conflict data in place, to be
> removed by update/switch to the same URL_at_REV. An update/switch
> to a different URL_at_REV would create a new tree conflict with
> resolved=FALSE.

Neither design takes into account possible things the user
may have changed locally in-between updates, so that e.g.
there is now a different *type* of tree conflict on the same
node with the same URL_at_REV.

So we might be getting into comparing more fields than just URL_at_REV,
which leads us to the question whether a victim may have multiple
tree conflicts or not... we didn't want to go that route, AFAIK :)

And how would commit behave in either design?

Quick hack:

Should we consider a flag to disable tree conflict detection during
update so could people unfold the cirucular dependency
update->resolve->update->resolve->... by disabling tree conflict
detection temporarily?

Or should we even consider adding such a --no-tree-conflicts flag
for all of update/switch/merge?

I know that this isn't the proper solution, but would help
as a last resort to get people out of circular-dependency
situations like this, should they run into them.

> A third alternative is simply to not include update/switch tree
> conflicts in 1.6.

AFAIK Hyrum wants to branch 1.6 by the end of the week.
So if we get this issue settled before the end of the week,
there's no problem at all.

If we don't, we can backport a fix before 1.6 release.
Surely we'll find a solution before christmas?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org