5

It has recently happened that a coworker, after completing some minor changes to the Stable branch of our solution, accidentally checked-in some of his unfinished work on the Development branch as well. TFS bundled it all up as a single changeset.

While the mistake was easily detected and fixed, I feel like I am missing something critical here. Why would TFS's "Pending changes" page allow you (and, worse, offer by default) to create a single changeset containing everything you've done on every branch?

It seems to me that a changeset should consist of changes to one and only one branch, so you can more effectively manage/merge/rollback them as necessary, without affecting other branches. If you have been working on multiple branches at the same time, upon checking-in it should ask you to insert multiple descriptions, and create multiple changesets as a result.

Assuming my reasoning is at least valid (if not necessarily universal), is there a way to configure TFS so that users may not check-in changes to more than one branch at a time?

EDIT: Failing that, I would appreciate a way to at least set the 'Pending Changes' page to put all changed files by default in the 'Excluded' section, so users will need to manually include them before checking in (which would help them notice any accidental changes).

piaste
  • 2,038
  • 11
  • 20

2 Answers2

6

Best practice: A developer can check in pending changes limited to a given folder/branch by right-clicking the folder, choosing "Check in pending changes". For that check-in action, the "Pending Changes" view will temporarily "exclude" any changes made outside of that folder/branch until you complete the check-in.

Can it be prevented: Per Microsoft, there is a premade Check-in Policy option known as "Enforce check-in to only contain files that are part of current solution". This may work for you, assuming you use "Solutions".

Why is this allowed: I suppose it's just how TFS was designed. I'd suspect it's to do with the treatment of branches as folders, and allowing check-in's across folders leaks into allowing check-in's across branches.

James Daily
  • 587
  • 6
  • 21
  • I can't find that premade policy anywhere. Any tips on how to activate it? – Geeky Guy May 18 '16 at 12:51
  • 2
    I haven't used this myself, but here is the documentation from Microsoft: Right-click your team project > Team Project Settings > Source Control > Check-in Policy > Add > Select "Code Analysis" > Select "Enforce check-in to only contain files that are part of current solution" > click OK [ https://msdn.microsoft.com/en-us/library/ms181459.aspx ] – James Daily May 19 '16 at 14:39
3

I can think of some scenario where this could be useful, like applying a critical fix on both release and main branches and merge is not an option.

What you can do to minimize the risk is to reduce the scope of developer workspaces as suggested by Jesse in Check-in each project separately?.

Community
  • 1
  • 1
Giulio Vian
  • 8,248
  • 2
  • 33
  • 41
  • 1
    Switching to multiple workspaces per user (one per branch) would certainly avoid the issue. The drawback is that switching workspaces is somewhat clunky and error-prone (you have to go through drop-down menus in both Team Explorer and Source Control Explorer, and there's no on-screen information on your current workspace), while users are currently used to just closing the solution file for one branch and opening the one for the other. And switching between branches happens often throughout the day (if only to test how a feature worked or whether a bug was present in the stable). – piaste Aug 07 '14 at 10:55
  • I created a Checkin policy which explicitly prevents people from checking in files across multiple branches in the same checkin. https://github.com/jessehouwing/tfstools a blog post explaining the policy is found here: http://blog.jessehouwing.nl/2014/01/creating-check-in-policy-to-warn-when.html – jessehouwing Apr 04 '16 at 11:18
  • 1
    Why would a merge ever not be an option when needing to apply a fix to two branches? If there is such a case, then I'd say it would just be better to simply check in the same change twice (once for each branch) rather than have a changeset that spans two branches. – Adam Goodwin Apr 14 '16 at 22:29