Details
-
Bug
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
trunk
Description
Message-ID: <20081125175514.8czsxnaeowgo4448@mail.elegosoft.com> Date: Tue, 25 Nov 2008 17:55:14 +0100 From: Stephen Butler <sbutler@elego.de> To: dev@subversion.tigris.org 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@REV occurs, it will remove the resolved- version data and not create a tree conflict. An update/switch to a different URL@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@REV. An update/switch to a different URL@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
Original issue reported by sbutler
