When you would like to know what changes have been merged already between a source and a target you can run:
tf merges sourceItemSpec targetItemSpec
Usually you would like to view the merge history recursively when you are using folders are branch roots (it’s recommended to use folders as branch roots, don’t use files as branch roots). The /r option will allow you to see merges between the folders and their child items too. If you don’t supply /r you will only see merge history of the folder itself (which usually consists of renames, deletes, etc.) and it wouldn’t be much. You can also run the command without specifying the optional argument sourceItemSpec to view all the merges that were applied to that target regardless of the source.
The output of the command looks like the following:
Changeset Merged in Changeset Author Date
——— ———————— ——————————– ———-
120 130 DOMAIN\userName 2/2/2009
150 200 DOMAIN\userName 3/3/2009
The first column shows you the changeset that was merged or ported over from source to target, and the second column shows the changeset when this merge was committed.
When you would like to view the changesets/versions that weren’t merged from source to target yet, you can run:
tf merge /candidate sourceItemSpec targetItemSpec
Again, usually you would like to use the /r option with this command too. The output of this command looks like:
Changeset Author Date
——— ——————————– ———-
210 DOMAIN\userName 4/4/2009
220 DOMAIN\userName 5/5/2009
These are the candidate changesets for the next merge. Merging up to the latest version will pend these changes on the target, you will see something like this:
merge, edit: $/Proj/Src/File.cs;C205~C220 -> $/Proj/Tgt/File.cs;C207
This means that you are going to merge the changes from the source between changeset 205 (the first changeset after the last merge from source to target) and 220 (latest version of source) to the target item at version 207 (latest version of target). The merge command allows you to merge cherry-picked changesets or merge up to a specific version of source. For example, if you run:
tf merge /r $/Proj/Src;100 $/Proj/Tgt
Since you specified changeset 100 (you don’t need to use the C prefix, it’s the default) it’s like requesting a merge for versions 1~100 of source which were already merged, hence, you will see a message indicating that "There are no changes to merge."
When the merge change is committed, the merge history of the target is updated, and credit is given to the merge. Next time you merge, you wouldn’t see these changes again, unless you force them to be merged again using the /force option, and subsequently they wouldn’t show up in the candidates list. Of course, the merge history will show one more entry after the merge. If you want to ignore the changes but at the same time give credit for the merge, you can use the /discard option. This will pend only the merge change without any other accompanying change, just like what happens when you resolve a conflict as keep target. Again this will record the merge operation in the merge history.