On Tue, Nov 25, 2008 at 11:55 AM, Stephen Butler <sbutler_at_elego.de> 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.
>
> 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!
>
> 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?
What I was expecting to have happen was for the item to become
unversioned in my WC as it always has. I still think that is closer
to correct behavior because when I update I expect my BASE to reflect
the repository. If the item becomes unversioned, some of this
scenario becomes easier to deal with.
There is at least one significant problem with doing it the way I
suggest, and that is that the user could not easily use svn diff to
get a snapshot of the changes they had been making. They would still
have the complete file.
It might be interesting to investigate a new WC state for an item that
is unversioned but has a tree conflict. Perhaps an item like this
could still live in entries and still have a text-base for diff. svn
resolve would have the option of scheduling the item for addition back
to the repository, or removing it from the WC. svn revert could
remove it from the WC.
It is nice that the current approach makes it easy to produce a diff,
but I do not really like that the item reports itself as 'M'odified as
that suggests it is still a versioned item that can be committed --
when it cannot be.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-25 20:00:13 CET