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

Quoting Stephen Butler <sbutler_at_elego.de>:

> 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.
>
> 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!

(replying to myself ;)

The fresh tree conflict is not exactly wrong, because the existence of
the local mods means that the tree conflict still exists "on the
ground".

A user workaround is to

   1. non-svn-move the modified victim elsewhere

   2. resolve the victim

   3. update (deleting the victim & descendants)

   4. copy the old victim back into the wc

   5. non-svn-move the modified victim back, overwriting the old
      version

This is awkward for directory victims, which take .svn dirs with
them. The user should run svn export to extract unversioned items.

Fixing this issue would allow the user to

   1. resolve the victim

   2. update (deleting the victim & descendants, leaving local mods
      unversioned)

   3. non-svn-move the local mods elsewhere

   4. copy the old victim back into the wc

   5. non-svn-move the unversion local mods back, overwriting the old
      version

Because svn copy doesn't support a --force option like update and
switch do, the use has to move the modified victim manually before
copying the older version into the working copy. At least, it's
easier this way, moving a nonversioned victim.

Comparing the two workarounds above, the difference isn't as stark as
I first expected. I suppose svn copy --force would be nice to have.

Fixing this issue would require changing the data structures in the
working copy library, and changing the behavior of commands that
create and read tree conflicts. Is that allowed after branching 1.6?

Steve

>
> 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.
>
> A third alternative is simply to not include update/switch tree
> conflicts in 1.6.
>
> Comments, anyone?
>
> Steve

-- 
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org