"$(ProgramFiles)\WinMerge\WinMergeU.exe" /e /u "$(Base)" "$(Mine)" /dl "$(BaseName)" /dr "$(MineName)"

Just quickly the following options do the following things:

• /e – enables you to dismiss the diff dialogue with the escape key
• /u – doesn’t add any of the path’s to the winmerge MRU (most recently used file list) since this is part of another workflow inside VS.
• /dl “$(BaseName)” and /dr “(MineName)” – makes the WinMerge display nice titles in the viewer title bar (instead of the full svn file path which can sometimes be long and cryptic) like this:
  • Web.config – BASE
  • Web.config – 54839

I’ve been using Subversion since the mono project adopted it many years ago, and was an instant convert. At the time the only real SCM systems I’d used before that were Visual Source Safe (VSS) or cvs. Subversion was such a breath of fresh air. (I’ll save my rant for any dev team with more than two devs in it that’s still using Source Safe when subversion is available for another time.)

Anyhow since then I’ve pretty much adopted or championed subversion use at any place I worked at because for some strange reason they all seemed to still be using Source Safe even with it’s issues with network access, VPN access, scalability, database corruption and uselessly slow history retrieval (I know I lied when I said I’d save the rant for later).

I continued to be impressed with the availability of tools to use with subversion from client side (tortoisesvn, ankhsvn) to server side (viewvc, mantisbt, redmine, reviewboard) which combined together help make an end-to-end high performance software development environment and process (I’ll definitely save those discussions for more posts to come).

Anyhow, now that Microsoft has released Team Foundation Server (TFS) it’s worth considering that most teams will be moving from VSS to TFS. And all indications are that a correctly configured TFS system is everything that VSS wasn’t.

So to get to the originally intended point of this post, svnbridge enables you to run a local svn server (in your taskbar) that actually proxies all it’s calls to a TFS system. This enables your developers to continue working locally with an svn working folder and therefore be able to use all the other svn integrated tools you may have included in your development process, while having your source code repository actually sit in TFS.

Now it’s relatively fresh software, in that it’s only just been released but I’ve actually used svnbridge and was impressed with how it does a direct mapping for most svn SCM operations to TFS operations including the obvious commit messages, branches and revision sets.