Will TFS 2010 support non-contiguous merging?

Question

I know that merging non-contiguous changesets at once may not be a good idea. However there is at least one situation in which merging non-contiguous changesets is (probably) not going to break anything: when there are no intervening changes on the affected individual files. (At least, it wouldn't break any worse than would a series of cherry-picked merges, checked in each time; and at least this way you would discover breakage before checking in).

For instance, let's say you have a Main and a Development branch. They start out identical (e.g. after a release). They have two files, foo.cs and bar.cs.

Alice makes a change in Development\foo.cs and checks it in as changeset #1001. Bob makes a change in Development\bar.cs and checks it in as #1002. Alice makes another change to Development\foo.cs and checks it in as #1003.

Now we could in theory merge both changes #1001 and #1003 from dev-to main in a single operation. If we try to merge at the branch level, dev-to-main, we will have to do it as two operations. In this simple, contrived example it's simple enough to merge the one file - but in the real world where there would be many files involved, it's not so simple.

Non-contiguous merging is one of the reasons given for why "merge by workitem" is not implemented in TFS.

Answer 1

TFS 2008 added the ability to extend the range of an already pending merge. That is, you could do:

tf merge $/dev/foo.cs $/main/foo.cs -version:~1001
tf merge $/dev/foo.cs $/main/foo.cs -version:~1003
tf checkin

Plus, you've always had the ability to pend multiple merges that don't touch the same files.

tf merge $/dev/foo.cs $/main/foo.cs
tf merge $/dev/bar.cs $/main/bar.cs
tf checkin

But beyond that -- no, 2010 does not add any new capability in this regard. My 1st sequence of commands would still be blocked if there were any intervening conflicts.