Tree Conflict Resolutions

USE CASE 1 (local delete, incoming edit upon update)

Description:

Developer A modifies Foo.c and commits it to the repository.

Developer B has simultaneously moved Foo.c to Bar.c in his working copy.

Results of Developer B’s Update:

Foo.c is deleted from working copy.

Bar.c is an add, without Developer A’s modifications to Foo.c.

Tree conflict on Foo.c.

Developer B’s Recovery Options:

Step 1:

Merge Developer A’s modifications to Foo.c into Bar.c.  If the working copy has a resource that is scheduled for add, and the copied-from URL of that resource is equal to the tree-conflict resource URL, then this is the default merge target (Bar.c in this example).

Step 2:

Mark Foo.c tree conflict resolved (from Tree Conflicts view, since it is deleted from working copy).

USE CASE 2 (local edit, incoming delete upon update)

 

Description:

Developer A moves Foo.c to Bar.c and commits to repository.

Developer B modifies Foo.c in his working copy.

Results of Developer B’s Update:

Bar.c is in working copy with Foo.c modifications merged in (I understand we cannot rely on this).

Foo.c is an Add in working copy.

Tree conflict on Foo.c.

Developer B’s Recovery Options:

Step 1:

If necessary, merge Foo.c changes  into Bar.c.

Step 2:

Revert Foo.c.  Foo.c is now unversioned and the tree conflict resolved.

Step 3:

Delete Foo.c from working copy.

 

USE CASE 3 (local delete, incoming delete upon update)

 

Description:

Developer A moves Foo.c to Bar.c and commits to repository.

Developer B moves Foo.c to Bix.c.

Results of Developer B’s Update:

Foo.c is a Delete.

Tree conflict on Foo.c.

Bar.c is up to date.

Bix.c is an Add.

Developer B’s Recovery Options:

Option 1 (Choose Bix.c):

Step 1:

Delete Bar.c.

Step 2:

Mark Foo.c conflict resolved.

Option 2 (Choose Bar.c):

Step 1:

Revert Bix.c.  Bix.c is now unversioned.

Step 2:

Delete Bix.c from working copy.

Step 3:

Mark Foo.c conflict resolved.

 

USE CASE 4 (local missing, incoming edit upon merge)

 

Description:

Developer A modifies Foo.c and commits to repository.

Developer B moves Foo.c to Bar.c and commits to repository.

Result of Developer B’s Merge:

Tree conflict on Foo.c.

Developer B’s Recovery Options:

Step 1:

Merge Developer A’s Foo.c changes into Bar.c.

Step 2:

Mark Foo.c conflict resolved.

USE CASE 5 (local edit, incoming delete upon merge)

 

Description:

Developer A moves Foo.c to Bar.c and commits it to the repository.

Developer B modifies Foo.c and commits it to the repository.

Results of Developer B’s Merge:

Bar.c is an add.

Tree conflict on Foo.c.

Developer B’s Recovery Options:

Step 1:

Merge Developer B’s Foo.c changes into Bar.c.  The dropdown for selecting the merge target is populated with all the Adds in the working copy.

Step 2:

Delete Foo.c from working copy.

Step 3:

Mark Foo.c conflict resolved.

 

USE CASE 6 (local delete, incoming delete upon merge)

 

Description:

Developer A moves Foo.c to Bar.c and commits it to the repository.

Developer B moves Foo.c to Bix.c and commits it to the repository.

Results of Developer B’s Merge:

Bar.c is an add.

Bix.c is up to date.

Tree conflict on Foo.c.

Developer B’s Recovery Options:

Option 1 (Choose Bix.c)

Step 1:

Revert Bar.c.

Step 2:

Delete Bar.c from working copy.

Step 3:

Mark Foo.c conflict resolved.

Option 2 (Choose Bar.c)

Step 1:

Delete Bix.c.

Step 2:

Mark Foo.c conflict resolved.

Option 3 (Choose both)

Step 1:

Mark Foo.c conflict resolved.

USE CASE 7 (local delete, incoming edit upon switch)

 

Description:

Developer A modifies Foo.c and commits it to the repository.

Developer B has simultaneously moved Foo.c to Bar.c in his working copy.

Results of Developer B’s Switch:

Bar.c is an Add, without Developer A’s modifications to Foo.c.

Tree conflict on Foo.c.

Developer B’s Recovery Options:

Step 1:

Merge Developer A’s modifications to Foo.c into Bar.c.

Step 2:

Mark Foo.c tree conflict resolved.

USE CASE 8 (local edit, incoming delete upon switch)

 

Description:

Developer A moves Foo.c to Bar.c and commits to repository.

Developer B modifies Foo.c in his working copy.

Results of Developer B’s Switch:

Bar.c is in working copy without Developer B’s Foo.c modifications.

Foo.c is an Add in working copy.

Tree conflict on Foo.c.

Developer B’s Recovery Options:

Step 1:

If necessary, compare Foo.c and Bar.c and copy Foo.c changes into Bar.c.  If compare option is selected, other options will be deferred until after compare editor is closed (user will be prompted to reopen dialog).

Step 2:

Revert Foo.c.  Foo.c is now unversioned and the tree conflict resolved.

Step 3:

Delete Foo.c from working copy.

USE CASE 9 (local delete, incoming delete upon switch)

 

Description:

Developer A moves Foo.c to Bar.c and commits to repository.

Developer B moves Foo.c to Bix.c in his working copy.

Results of Developer B’s Switch:

Foo.c is a Delete.

Tree conflict on Foo.c.

Bar.c is up to date.

Bix.c is an Add.

Developer B’s Recovery Options:

Same as USE CASE 3 (local delete, incoming delete upon update).
USE CASE 10 (local add, incoming add upon update)

Description:

            Developer A adds Foo.c and commits it to the repository.

            Developer B simultaneously adds Foo.c.

Results of Developer B’s Update:

With latest build, this no longer causes a tree conflict.  Instead, results in a file conflict on Foo.c.

Note:  local unversioned, incoming add upon update does not generate a conflict.

USE CASE 11 (local obstruction, incoming add upon merge)

 

Description:

Developer A adds Foo.c and commits it to the repository.

Developer B adds Foo.c and commits it to the repository.

Results of Developer B’s Merge:

            Tree conflict on Foo.c (status is normal in working copy).

Developer B’s Recovery Options:

Step 1:

Open compare editor to compare working copy version to Developer A’s version in repository.

Step 2:

Upon close of compare editor, prompt Developer B to mark conflict resolved.