Microsoft Team Foundation Server and Beyond Compare
Simply put, I can't stand any other comparison tool than Beyond Compare. This is a product that definitely earns the name!. I would pay more than Abraxis Merge for Beyond Compare, but I don't have to, as they are also the most reasonably priced tool I've ever seen. I use Beyond Compare to do file differences, directory comparisons, heck I use it to upload the latest version of XBox Media Center to my hacked XBox (I use the pimped edition). I'm also using Microsoft Team Foundation Server's source control. Here's how to set Beyond Compare up as the comparison tool: In Visual Studio, click menu File / Options... Expand Source Control in the treeview. Click Visual Studio Team Foundation Server in treeview. Click button Configure User Tools... Click button Add... Enter .* in the Extension textbox Choose Compare in Operation combobox Click button ... next to Command textbox Browse to BC2.EXE in file chooser and click button Open Enter %1 %2 /title1=%6 /title2=%7 into the Arguments textbox. Ok on out. Microsoft's version of these instructions is here. UPDATE: James Manning has comprehensive instructions for other tools here. Now one issue remains, and hopefully either Microsoft or Scooter Software will do something about it. When using an external comparison tool Visual Studio checks both files out to a temporary directory. It appends a tag to indicate the file version. The suffix looks something like ;C19 where the C indicates this is a changeset, and the 19 is the changeset number. It's also possible to see an ;Lxxx which indicates a label xxx. For more information on the suffixes, see this at the Versionspecs section. UPDATE #2 and #3: Both Microsoft and Scooter have addressed this, the RC of VSTS now preserves the file extension; using the suggestions below will improve the display in BeyondCompare until then. This means the external diff tool command line is something like "BC2.EXE Foo.cs;C19 Foo.cs;C22". In Beyond Compare, the funky changeset tag interferes with the file-extension sniffing in Beyond Compare. The actual quick "files are different" compare thinks these are "any other file", so no rules are run. Secondly, when the viewer for different files is run, it also thinks these are "any other file", so no language-specific or file-extension specific plug-ins run. What is needed is to have Beyond Compare have the comparison and the viewer strip off everything after the last ";" from each filename before determining which rules to run and which viewer to launch. The other option is for Microsoft to not create these oddly named files and instead create a subdirectory for each file that reflects the version/changeset/label, etc. Personally, while I think that the filenames are odd, I'm hoping for a fix from Scooter Software. Why?
- Having the suffix on the filenames clearly indicates which one is which in the view header.
- Scooter Software moves like an ice-cube on a hot griddle.
- Microsoft, especially this close to release, moves like a glacier.
Posts
13 comments:
As predicted, the gang at Scooter Software moved quickly in a temporary work-around. I can add an * to the Rule patterns. This is not a complete solution in that viewers (like the Image Viewer) that sniff the file extension are still not getting the right information, and the rules will match too agressively depending on the order in the rules (e.g. .aspx* will match Foo.aspx.cs unless the .cs* rule comes first), but it is a good start. Thanks, Craig!
Well, we are pretty close to release (having shipped Beta3), but this is not the first tool to have problems with how we're choosing our temporary filenames. I'll bring it up tomorrow and we'll see if it's something we can change for V1.
Thanks for the feedback, Marc!
By the way, we construct labels that should be helpful for understanding the 2 files you're editing better. In Beyond Compare, you would use the /title1 and /title2 parameters, so I would recommend setting your Arguments to:
%1 %2 /title1=%6 /title2=%7
Hopefully that will work a little better for you (it works here, it puts the labels in the drop-down initial text and in the window title).
Thanks for the hints and response James. You've made me eat my pessimistic words. The /title1=%6 /title2=%7 does indeed improve the experience.
Any clues on what the %5 actually passes for various compare scenarios?
%5 passes any command-line options you decide to specify with /options. For instance, if you decided "for this particular diff, but not in general, I want to use bc2.exe's /readonly option and rule foo" then you could do: tf diff /options:"/readonly /rules=foo" somefile.cs
When we run the command (and do substitutions on the variables, %1, %2, etc.) the %5 variable, if it's in your Arguments entry, will get substituted with the string you passed in for /options.
FWIW, this is how Visual SourceSafe's interface worked (%1 through %9, %5 for options) for 3rd-party tools, so we kept it the same to ease migration for those users that were used to configuring tools there.
That makes sense for the command-line arguments, but I'm not sure where in the VisualStudio context it comes in (I suspect it doesn't). In other words, where is the options set when doing a Right-Click Compare?
One other thing I dearly miss versus the VSS interface is the ability in the Source Control Explorer to compare all files in a workspace. As it stands now, I have to do a get-latest into a seperate workspace and then use Beyond Compare to compare the two directories... it would be COOL to be able to compare entire directory trees like VSS let me do..,
Directory compare is V2 at this point, but it's a common request.
One side note, the current version of this post says:
Leave the default in Arguments textbox (which is %1 %2 /title1=%6 /title2=%7).
That implies the default value includes the /title1 and /title2 arguments, which isn't true.
Fixed, thanks.
You'll be happy to that the extension handling has been fixed for RTM. The change got approved and James recently checked in the fix (the version now appears before the extension instead of after it).
Thanks tons guys! I like the new Agile Microsoft :)
The blog post still makes it sound like we're going to be using the temp files with the busted extensions. If you get a chance, it'd be great to update it with a quick note that we fixed the issue for the post-beta3 bits in case others run across this and aren't patient enough to read the comments :)
Hi Marc!
Hopefully by now you're running the RC bits and you've been able to get rid of the * you added to your rules as our extensions are back to what they should be.
I just wanted to mention that I added these Beyond Compare values to a new blog post where I'm going to track command/argument values for various diff/merge tools.
http://blogs.msdn.com/jmanning/articles/535573.aspx
i am a fan of beyond compare like you. just configured it, took me 2 minutes, and well, it works perfect. coooooolicoooooooooooo !
cheers
thomas
Post a Comment