I'm working to establish a source control solution that will allow multiple vendors to contribute to a single project (multiple Sitecore CMS sites in a single installation). Ideally we'd like to go with TFS as it seems to fit our in-house requirements and support best. Some of our vendors, however, prefer SVN. If we choose to go with TFS there seem to be a number of possible solutions to this.
1) Vendors commit to using TFS directly, using MS tools and CALs(e.g. Visual Studio for back end devs and tfs.exe etc for front end).
2) Vendors use TFS, plugging in with and adaptor to their current SVN tools (SVN Bridge / SVN Tortoise) - still requires a CAL per developer.
3) Vendors use a single CAL to establish a codebase from the TFS which they then use as an SVN repository. Vendors use SVN locally but use continuous integration between the SVN repository and the TFS to keep in synch.
The third option looks cheaper in licensing terms, but would add considerable complexity and developer time in the synching, and would presumably lose check-in info on a per developer basis (a single dev would check in all changes by his team to the TFS).
We don't actually need a great level of detail and sophistication, just basic functionality. The vendors are responsible for their teams, we don't even really need to know who did what at that level, just that it came from vendor A or vendor B.
What are the relative drawbacks and benefits of the approaches above, and what tools would make my life easier?
As you point out, you do have several options here:
If your vendors simply want to use Windows Explorer-like integration (similar to Tortoise tools) they can install the TFS Power Tools which include Explorer integration. While this option will require your vendors to learn new tools (and thus may be a bit frustrating at first), this will certainly have the fewest number of "moving parts" and potential for breakage.
Is probably the most difficult route. While SVNbridge is excellent at many things, it will probably not provide all the functionality that your users will require, for example, branching and merging.
Timely Migration offers a SVN to TFS Migration Tool that is useful for a first-time SVN to TFS migration, but (if I recall) does have some manual resolution steps that would make it more difficult to use in an automated manner. However, this may be worth investigating how it could be used for synchronization. On this point, however, you should consult with your Microsoft contact regarding CAL licensing: using an automated tool to synchronize between TFS and another system does not necessarily remove CAL restrictions.