Welcome to MSDN Blogs Sign in | Join | Help

A new spec on conflict resolution is available

 

We've gotten feedback that branching, merging and conflict resolution are too complicted today.  We are making a series of improvements in our next version of TFS to address these issues.  The new history spec we released a couple of months ago demonstrated one piece of our plan - allowing you to easily track a change across branches back to the original checkin that introduced it.  Today, we released a new resolve spec that covers improvements to conflict resoluton.

Our resove design is intended to address the following issues:

  1. The resolve dialog is modal and hinders my ability to effectively perform any research necessary to resolve the conflict
  2. To resolve some conflicts like a rename I end up clicking four different modal screens before the conflict is resolved and once again I cannot effectively perform any research throughout that flow
  3. The resolve screen does not show enough information about why the conflict was filed (i.e.. series of events that led to it) which requires me to do, at times, extensive research in order to select the appropriate resolution
  4. The resolution options are not the same between the UI and the command line and in addition it is hard to know what the end result will be by choosing the option
  5. There is no UI that will allow me to resolve a conflict where two items are trying to occupy the same path/name *

Here's a screen shot of the new modeless conflict resolution channel in the Pending Changes tool window.

See the spec referenced above for more details and don't forget to provide any feedback at: http://forums.microsoft.com/MSDNWorkShop/ShowForum.aspx?ForumID=1981&SiteID=64

 

Brian

Published Friday, February 01, 2008 8:26 AM by bharry

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# re: A new spec on conflict resolution is available

A .pdf would be useful for those of us without all MS's latest-and-greatest products.

Friday, February 01, 2008 9:46 AM by Dave

# re: A new spec on conflict resolution is available

I hear you.  I went through some debate on this when we first published our specs.  We're told all specs on this site are to be published in xps format.  I dug into it a little bit and there were claims that the format does a better job preserving the original Office doc format among other things.  Fortunately, the xps viewer is pretty easy to download/install.

I'll pass the feedback along though.

Brian

Friday, February 01, 2008 11:15 AM by bharry

# re: A new spec on conflict resolution is available

These are all issues that need to be addressed.  One thing about the UI prototype above.  The text "Take Server Version" and "Keep Local Version" works fine for normal checkin conflicts.  However when merging branches, I prefer that the button text reference "source" and "target" which how I think about the two entities in a branch merge.

Friday, February 01, 2008 5:08 PM by Keith Hill

# re: A new spec on conflict resolution is available

BTW you guys should work with the Visio team to come up with a template set for software branches.  That'd be cool for documenting a project's branching structure.

Sunday, February 03, 2008 1:25 AM by Keith Hill

# re: A new spec on conflict resolution is available

Thanks for the feedback.  Regarding server/local vs source/target, that's exactly what we do.  The take/keep is consistent but the noun changes to be clear in the two scenarios.

Brian

Monday, February 04, 2008 7:54 AM by bharry

# re: A new spec on conflict resolution is available

I think the same terminology should be used for the command line as for the UI. Server and Local make more sense that Yours and Theirs.

Monday, February 04, 2008 1:54 PM by Dave

# re: A new spec on conflict resolution is available

Some other items of concern:

1. Folder renames seem to introduce a pain and danger into normal workflow and merge scenarios (especially top level folder renames, like branch renames).  

   -Users in the tree who did a partial GET have reported seemingly losing files (or at least got very confused)

   - Users in the target branch of a merge after a rename who had files pending out while someone else did the rename found a conflict when they checked in they could not resolve saying changes happened in both versions when all that really happened was a rename.

2.  There should be better support for baseless merges in the interface.  Inevitably someone does a rename or wants to marge to a parent of a parent branch or what have you and can't do this through the UI. (Or someone deleted and re-added the same file (actually the VS IDE inappropriately does this in solution explorer instead of a move and breaks merging)

- Having an easy way to determine and fix the merging for these branching disconnects due to file deletes and re-adds through a UI baseless merge option would be beneficial.  (maybe show files/as a same slot conflict but allow an option of baseless merge on that file or files.

- There are cases where multiselected items did not properly offer all options for merging.  Tried to say take changes only from source branch but that option was not available in multiselect of files but was there when files were individually selected.

---------------------------------------------

An aside:

A nice safety feature before any merging would be an option to autoshelve changes (and maybe even drop a label on your workspace versions),  This allows restoring to the original changed files if the merge goes badly.

(TFS has all the functionality to support this already.  Currently I'm doing this manually before I do GET's, checkins or merge's.)

Monday, February 04, 2008 2:19 PM by Dave

# re: A new spec on conflict resolution is available

Hi Dave:

Thanks for your feedback. In regards to the command line use of Yours and Theirs we decided to leave the wording because we needed one option that was general enough for all of the cases (e.g. Merge, Rollback, Get). For merge we cannot use server and local since source and target is really what we want. Our solution was to change Accept to Take or Keep allowing the visualization of the flow of data.

Wednesday, February 06, 2008 8:26 AM by mrod

# re: A new spec on conflict resolution is available

Hi Dave:

You make an excellent point on the complication of merging renames and delete/adds. We are currently looking very hard at these problems to try to find the right answer. In the next iteration of resolve we will make investments in the resolution of filename collisions allowing you to baseless merge them right there in the UI.

We have also captured your other feedback and will continue to work to make those scenarios and flows better for our customers.

Thanks, mario  

Wednesday, February 06, 2008 8:31 AM by mrod

# re: A new spec on conflict resolution is available

We desperately need a way to establish or re-establish merge linkages as well.  We had some issues getting up and running, and one of those was that a whole mess of files was checked into two different branches, rather than checked into one and branched to the other.  These files are 90% identical, but by the time it was discovered, 10% had had edits to them.  There was no way to merge changes at that point.  

I resorted to re-branching each file by hand, but the side effect of that was that right-clicking on the folder to merge wouldn't allow the merge, even though right-clicking on each individual file would.  Ugh!

I need to be able to tell TFS that THIS branch has a merge relationship with THAT branch, and it should just go through and establish it.  Where the files are identical, it's a no-op.  Where they're different, the normal conflict resolution should kick in.

Additionally, why can't I multi-select files in order to branch or merge?  I've needed or wanted this countless times.

Oh, and after merging or branching a file, why all the (very slow) UI screen refreshes?  This can be horrible if buried deep in a large tree (in one case, I can go out and get a cup of coffee before it finishes refreshing the screen, as it apparently walks every sibling folder).  Additionally, it loses the selection, forcing you to scroll down if the file was at the bottom of a long list.  All these things are extremely painful.

True, in an ideal world, most of these features wouldn't be too necessary, but in the real world, mistakes happen, and we need ways of recovering from them easily.  Being able to say that two branches SHOULD have a merge relationship is seriously high on my list of requested features.  For some reason the /BASELESS merge in the command line simply doesn't do the trick (oh, it sorta works for the command line, but the UI itself never seems to pick up on the fact that the branches should now have a merge relationship).

Wednesday, February 06, 2008 9:59 PM by PaulB

# re: A new spec on conflict resolution is available

I second PaulB's comments enthusiastically.  As our port progesses, even with careful up-front planning, merges from the production VSS database are getting progressively more painful and dangerous.  Not really bad yet, which is a strong positive for both the existing feature set and the process guidance documentation that fed into my planning.  But it gets progressively worse every day and we haven't really started refactoring yet.

Once we do start refactoring a new and much harder issue will emerge: when multiple new artifacts are formed from part of multiple old artifacts the merge trail becomes very difficult to follow.  Nevertheless, somebody has to watch for bug fixes in the old tree that need to find a home in the new.  That somebody is me right now so I'm worrying about it.

If new features to allow explicit creation of merge breadcrumb trails are being designed (like those suggested here or the "never merge" branch markings proposed in another thread) then the refactoring story needs to be considered.  When a change encounters a dead end in the merge path it shouldn't just silently fade into oblivion: I'd like a list of orphaned changes and I'd like a way to record the set of "old" artifacts that contributed code to a "new" artifact.  Note that the lifetimes of the donor and recipient artifacts are not necessarily begun and/or ended by the transplant operation.  If the merge tool can then make a good-faith effort to locate the affected lines in the target artifacts that would be all I could ask.

Related to PaulB's point is that when I do delete and re-branch a file to restore merge path integrity that has been lost for whatever reason, the history of the new file does not include changes to the old instance.  If I'm investigating an issue involving an earlier build (or product release!) this can be a problem.  I'm not convinced the merge visualization enhancements proposed a few weeks ago fix this but that's because I am only now becoming focused on the issue.

While on the topic of history visualization, a knock against the TFS UI from VSS users is that when you pull history on a file you get a list of changesets and it is tedious to drill into each one to get an overview of the nature of the changes involved.  Not that "add" "edit" "merge" and "branch" would be that informative but there is a perception that there is a loss of visibility in this scenario (single-file history visualization).

Friday, February 15, 2008 9:46 AM by Steve Nuchia

# re: A new spec on conflict resolution is available

Paul/Steve,

Yes, adding baseless support to the GUI is on our list for the next version.  In fact, once we get the visualizetion stuff done, some improvements across the board in the merge experience are on tap.

The changes we are making in history should help address your concerns about tracking history across branches/merges.

The issue of tracking merges across refactorings is really tough.  We've talked about this being a problem before but don't yet really have great ideas on how to tackle it.  We won't forget it though.

We have some more improvements coming in history that will help, at least a little, with "previewing" the nature of the change without openning the diff.  We agree there's room for some cool work here.

Thanks a ton for the feedback.  This stuff is hugely valuable.

Brian

Friday, February 15, 2008 10:11 AM by bharry

# Resolve improvements in next version of TFS

As Brian said long time ago in his blog ( http://blogs.msdn.com/bharry/archive/2008/02/01/a-new-spec-on-conflict-resolution-is-available.aspx

Sunday, May 04, 2008 10:12 PM by michal.Log

# 競合解決の新しい仕様を公開

分岐、マージ、競合の解決が現状では複雑すぎるというフィードバックが寄せられています。このような問題に対処するために、開発中の次のバージョンの TFS ではさまざまな改良を加えているところです。数か月前にリリースされた新しい

Wednesday, June 25, 2008 3:14 AM by bharry's WebLog

Leave a Comment

(required) 
required 
(required) 

  
Enter Code Here: Required
 
Page view tracker