Yes, We Still Use TFS

My employer uses Microsofty technologies in its backbone. We have a large, entertwined codebase that loads 150+ projects at once, and yes, we still use TFS, not git.

We mark some items for manual merge due to the quirks of our processes, using Visual Studio slns, and Reasons, okay for reasons.

The problem?

No, the answer isn’t that we still use TFS, and not distributed version control. I mean it is an aspect, but that’s not the problem. The problem is we have years of unmerged items due to some checkins requiring careful hand merging or manual changes.

Just trust me. For Reasons.

TFS means VisualStudio, and merging in the Visual Studio UI means retrieving merge candidates. And that list is long.

I don’t much care for lifting my hands from the keyboard, much less waiting for long lists to load OVER AND OVER, so, for the standard merge, I wrote a powershell script. Wait. No. I went further and wrote a MODULE.

I like tab completion

I could have used a library but our needs are simple.

  • Merge a changeset or range of changesets
  • Make the original comment (where we have a standard of including the work itemID as well) easily accessible.

This module isn’t not perfect. It doesn’t automatically setup or detect workspaces. It doesn’t checkin the subsequent merged files. You have to open it up and update

  • The path tfs.exe is suitable for your machine, are any paths to where you keep your local versions of the codebase.
  • That you’ve defined the names of any projects and your project default
  • The url to the collection on the server

But I went the extra bit, and wrote enums and a little baked in help, so that we can take advantage of civilized niceties such as tab auto complete.

So now, for our most commonly used project, instead of a lonnnnnng tfs command line command, do the following:

Merge-Code Dev Test <IntegerChangesetId> <IntegerOptionalEndofRangeChangeset>

I have tf.exe in my windows path, so this is more simplified than the average bear’s setup. And note — to merge a single changeset, you still have to specify it twice.

cd <local directory with repo files>
tf vc merge /recursive $/VersionControl/Source/Path $/VersionControl/Destination/Path /version:C<ChangesetId>~C<ChangesetId>

Merge conflicts open in their own window, and the pending items show up in VS. The script copies the checkin comment of the first changeset in the range, and I paste that in without having to look it up.

Not exciting, is it? But it vastly speeds up our workflows.

Get the goods


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *