• Comments 6

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.

Leave a Comment
  • Please add 6 and 3 and type the answer here:
  • Post
  • Hi. I have a situation where there are two code branches, one of which was branched off from the other, and a particular file in one of the branches has a number of changes. I'm trying to investigate one of the changes and whether or not it was ever merged up. Its changeset doesn't show up in the list generated by tf merges. However it also doesn't show up when I run tf merge /candidate. Any idea how that could happen? Shouldn't it appear in one or the other?  -- Mike

  • It depends on the direction. Are you looking at merge candidates from branch A to branch B or vice-versa? If the changes were made in B but you are looking at the merge candidates from A to B, they won't show up, to see them, choose the right direction, in this case: from B to A.

  • I am merging from branch A to B, and have made numerous changes in branch A, some of which have been merged to B. I've identified a couple changesets in branch A that I want to investigate. So I enter:

    tf merges $/BranchA/FileA $/BranchB/FileA

    where fileA is a file present in the changesets I'm investigating. It displays a list of changesets that have been merged from Branch A to Branch B, none of which is the one I'm looking for. This implies to me that the changesets haven't been merged yet.

    Next I enter

    tf merge /candidate $/BranchA/FileA $/BranchB/FileA

    and get a list of candidate changesets. However it does not contain the changesets I was investigating.

    It seems like any given changeset that was checked into BranchA/FileA should appear in one list or the other, no?

    -- Mike

  • I tried to reproduce the issue, here's my output:

    tf merges BranchA\File.cs BranchB\File.cs

    Changeset Merged in Changeset Author                           Date

    --------- ------------------- -------------------------------- ----------

        654                  655 mohamedg                         4/10/2009

        656                  657 mohamedg                         4/10/2009

        658                  661 mohamedg                         4/10/2009

        659                  661 mohamedg                         4/10/2009

        660                  661 mohamedg                         4/10/2009

        662                  665 mohamedg                         4/10/2009

        663                  665 mohamedg                         4/10/2009

    tf merge /candidate BranchA\File.cs BranchB\File.cs

    Changeset Author                           Date

    --------- -------------------------------- ----------

        664  mohamedg                         4/10/2009

    tf hist BranchA\File.cs /i

    Changeset Change                     User          Date       Comment

    --------- -------------------------- ------------- ---------- ---------

    664       edit                       mohamedg      4/10/2009

    663       edit                       mohamedg      4/10/2009

    662       edit                       mohamedg      4/10/2009

    660       edit                       mohamedg      4/10/2009

    659       edit                       mohamedg      4/10/2009

    658       edit                       mohamedg      4/10/2009

    656       edit                       mohamedg      4/10/2009

    654       add                        mohamedg      4/10/2009

    I tried edits in A and merging to B, and even merge with discard. As you can see, the set of versions listed in history is the union of merges and candidates.

    Please check the histroy of the file. You can also send me the actual data in an email:

  • Hi. Sorry for the delay in getting back to you. I've captured a good example & sent it to you in a  separate email. Thanks.

  • To make it clear for other readers. This can happen when the user has resolved a conflict as AcceptTheirs - hence choosing to never merge the previous changes. You can confirm this by looking at the file contents and check it against the file contents of the source version. The command tf merges wouldn't show implicitly ignored versions (AcceptTheirs) and it won't appear in the candidates list because you told TFS to ignore it.

Page 1 of 1 (6 items)