[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Tree conflict merry-go-round on update/switch

From: Stephen Butler <sbutler_at_elego.de>
Date: Tue, 25 Nov 2008 17:55:14 +0100

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?

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
Received on 2008-11-25 17:55:33 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.