Not sure if this is something else you still don’t know about, but now I have been using mercurial locally for a while, and so far I think the benefits outweigh the additional overhead of managing the two version control systems. Here is how I did it:
I made my TFS checkout a repository of HG, which I consider my "master". I get updates from TFS and bind them to this repo, so it contains the most current state of the project from TFS. The important thing is that there is no change in this regardless of the TFS update or the Hg merge (which is part 2)
Anytime I need to make changes, I clone my "master" repo and do my work. I found that the clone for each function or story is actually quite easy to manage and looks pretty clean. As soon as I complete the function, I return Hg back to the "master" repo, in which all TFS updates have been applied. This allows me to use the capabilities of the Merurials merge, which still surpass TFS, to question how TFS can claim code merging at all. Once the merge is complete, I commit it to Hg and then check these changes on TFS. The best part of this is that when I do a checkin for TFS, I don't need to merge anything. Very very nice.
Now here are the problems I found with this approach:
The biggest is the fact that TFS is disgusting in its search for change. There is a make writable plugin that you can use to make modified files writable when they are updated / merged by Mercurial. There are two options for this. You can either force TFS to go offline, and at this point it will suggest that you need to write something, or you can use the comparison tool in the version control tool and select the modified files and individually inspect them. Both are crappy imo
Source control links are still present at the project level, even if you exclude TFS source control files from your hg repository (what you need to do). This is not obvious until you add the file to the solution, after which it will try to add it to the original control. You can “Undo Pending Changes” and get rid of adding a version control, but it is really annoying.
The good news is that I used this approach to work through a rather massive merger, which, I think, would lead me to turn into some form of hard drug if I were forced to use TFS tools for this.
I have not used this to update branches in TFS yet, but I assume that it will be much better than the options you give for merging in TFS. In a related note, since you can check pieces of working functionality at the same time, using a TFS merge would be less problematic just because all the changes needed for a function would be merged in one place.
One thing that I did not try to solve was the exchange of it throughout the team. Part of the reason is that it really is not necessary for the whole team. I work remotely, so having local storage is a big deal and saves a lot of time. Other members of my development team may or may not get the same benefit from this approach, but I find it pretty cool that I can without effect how they work.
Update I would like to update this answer for some time with additional information based on comments and some of my experiences with large TFS repositories.
First, as @ Eric Hexter points out in the comments, you can use the redirect extension to better integrate commits from your working repositories into the main TFS repository. Although, depending on how you want your commits to appear in TFS, you can use collapse the extension to clip your changes into a single commit (this can make rollbacks to TFS easier). There is also an “online team” from TFS PowerTools that can do the job of letting TFS know what has changed easier (thanks again to Eric for noting that on his blog )
Now that I originally wrote this, I was working on a project that had only one TFS branch that the developers used and was pretty small, so cloning the repositories was unimportant. Later I discovered that I was working on a project that had a repo that was about 1.5 GB after verification, and a lot more after build, and often included switching between branches in TFS. Obviously, this approach is not suitable for this environment (in particular, since at some point it was impossible to create solutions in an arbitrary directory.
The size problem is best handled using a technique similar to branches of gits branches, rather than cloning repositories into new directories. There are a couple of options for this. I believe that it’s best to use the extension and create a bookmark theme rather than a topic thread. You can also use named branches, but they have a slight drawback - being persistent and traveling with any clones you can do (if you want to share your great TFS-Hg hybrid with a colleague). Bookmarks are local to your repo and effectively indicate commit and move with your head. They are implemented so that they can be used anywhere where Hg is awaiting revision (therefore merging, updating, etc.). You can use them to create TFS bookmarks as the main "branch", which receives only updates from TFS and merges with the work of the theme, each of which has its own bookmarks, and you can delete it after you return to TFS. If you prefer to use named branches, then you can use exactly the same methods that are convenient.
Now the problem with multiple branches is more complicated, especially since the TFS branches are actually copies of each file from the original branch, which means that every time you pull branches with TFS, your repo is going to get a lot more. One possible way to handle with this, use a combination of the named Hg branches and bookmarks, so that you have a branch for each TFS branch, and then bookmark your work from these branches. The real headache in these scenarios is actually related to the TFS workspaces through it all. You can remove the mappings in your workspaces and get pretty far, but as soon as you get back to your working directory, you should be careful with TFS stomping files (this is actually useful when TF PowerTools comes in handy). Trying to leave the workspace when connected when your switch branches get ugly. A couple of tools that are nice to have in your toolbox are the Hg cleaning extension and the TF PowerTools scorch command. Both effectively delete files that are not in version control (technically, "scorch" ensures that TFS matches your local working directory, so it can also update files).
For me, however, this process has become quite onerous and error prone. I recently switched to using git with git-tfs , since it manages the TFS workspaces for me and removes the heavy load associated with this side. Unfortunately, there is no "hg-tfs" anywhere, otherwise I would choose this.