Freigeben über

Merges

  • Artikel

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
…etc.

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.

Comments

  • Anonymous
    April 09, 2009
    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

  • Anonymous
    April 09, 2009
    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.

  • Anonymous
    April 10, 2009
    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

  • Anonymous
    April 10, 2009
    I tried to reproduce the issue, here's my output: tf merges BranchAFile.cs BranchBFile.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 BranchAFile.cs BranchBFile.cs Changeset Author                           Date

    664  mohamedg                         4/10/2009 tf hist BranchAFile.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: http://blogs.msdn.com/mohamedg/contact.aspx

  • Anonymous
    April 20, 2009
    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.

  • Anonymous
    April 28, 2009
    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.