Better Multi-User Support for Work Item Tracking in TFS 2012

Consider this scenario:

1. User A opens a work item (and keeps it open)
2. User B opens the same work item, makes a change, and saves it.
3. User A (with work item still open), decides to make a change.

In Team Foundation Server 2010 (and previous releases for that matter), support for multiple users editing the same work item at the same time was simple and blunt.

When User A makes a change (based on a now out-of-date version of the work item), he’s presented with the TF237079 error (again, I’m looking at TFS 2010 currently):

This occurs regardless of the field you modify (i.e. if User B changed “Description” and User A changed “Title”, this condition still rears its head).

Dang!  Now what?  You need to refresh the work item (to suck in the updated version), and lose your proposed changes (well, you have to input them again).  The work around for this is simple: If you like to keep work items open (for reference, or whatever) and don’t want to get “blocked” should you decide to make a later change, click the refresh button prior to making your changes.  This will reduce the chance that someone else slides in an update before you do.

Team Foundation Server 2012 handles this scenario more smoothly.

Let’s revisit the scenario I listed above.  When user A makes his change and clicks “Save”, TFS will check to see if the work item has already changed.  If it has, but User B’s change (say to “Description”) doesn’t conflict with User A’s proposed change (say to “Title), it just works (this condition is equivalent to merging in version control when there are differences but no conflicts).  TFS will save the User A’s change and refresh the work item for him (so now User A can see his save, as well as the updated field values from User B).  Basically, TFS will auto-merge work item updates when different fields are updated (i.e. no stepping on toes).

If the same field is has been updated by User B and User A, now you effectively have a true merge condition.  In this case, TFS will give you this message, TF248023:

Look at what the message is saying.  It’s not blocking you – it’s warning you that you may step on someone’s toes (i.e. there’s a direct conflict with a field you’re trying to update).  If you close this dialog and try to save the work item again, it will allow you to save!  Now ideally, you’d take a look at the work item history (per the dialog message) to see check on what changes you’re potentially overwriting before saving; so consider this message as a warning from TFS 2012 saying “I’ll let you save this if you really want to, but don’t say I didn’t tell you so if someone gets mad!”

So again, in previous versions of TFS, the above scenario doesn’t really work.  You’re forced to refresh the work item and re-enter your changes.  In TFS 2012, if there are no direct field-level conflicts, it works just fine.  If there is a direct conflict, you’ll get warned first.

Hope this makes sense!