0

Background

If I merge our main branch to our development branch, TFS will state that there are no changes to commit. And yet, a file level comparison (using WinMerge) clearly shows that there are differences (e.g. files missing, files with different content, etc.).

In short, our main and development branches are no longer in sync which is most likely due to changesets that were lost during previous TFS migrations.

Question

What is the best way to produce the following?

  1. Synchronizing the main and development branches by: performing all of the necessary insert/update/delete operations on the development branch. (i.e. main is the master copy).
    • At the end of the process WinMerge should indicate that there are zero (0) differences between the two branches.
  2. Keeping the development branch history intact.
  3. Notifying TFS that the development branch is now fully synchronized with main so that:
    • TFS won't try to merge older development changesets with main
    • only future changes to development will be pushed to main during a merge operation.

TFS is not my area of expertise - any guidance that you can provide would be greatly appreciated.

Context

  • Visual Studio 2015
  • TFS (version 14.95.25122)

References

  • Merge Command
    • "Performs a merge without a base version. That is, allows the user to merge files and folders that do not have a merge relationship. After a baseless merge, a merge relationship exists, and future merges do not have to be baseless."
      • Although Development was branched from Main, it looks like this might address my lack of history (i.e. missing changesets) problem.
  • TFS Merge: Best Practices
  • TFS: Overwrite a branch with another
    • tf merge A B -r -force -version:T
      • I don't think this will work for us because changesets are missing.
Community
  • 1
  • 1
Pressacco
  • 2,815
  • 2
  • 26
  • 45
  • File difference exist does not means that there is change can be merge from main to development. What's the result if you run "tf merge /candidate /recursive main development" and "tf merge /candidate /recursive development main" command? – Eddie Chen - MSFT Oct 06 '16 at 07:31

1 Answers1

0

When TFS does a merge, it bases the merge on prior merge history, not on the actual contents of the source and target files.

This issue may by caused by picking keep target when perform merge or at one time, a merge with the discard option performed (using the command line TF merge /discard).

To solve this issue, you can try to:

  1. Use the /force option with the tf merge command. If there is a changeset that was previously merged (perhaps incorrectly) and you want to merge it again. The /force flag ignores merge history that indicates a particular changeset was previously merged from source to target, and merges the changeset again.

  2. Undo the previous merge using Rollback. If you've recently done the merge in which changesets have been discarded. Find it in the history, rightclick the changeset and pick Rollback and check in the code that has been undone.

Cece Dong - MSFT
  • 29,631
  • 1
  • 24
  • 39
  • re: Cece's comment: _"The /force flag ignores merge history that indicates a particular changeset was previously merged from source to target, and merges the changeset again."_. This doesn't help because of how my employer migrated from TFS2012 to TFS2013. Long story short, I **cannot merge based on changesets** because the history is incomplete (i.e. changesets are missing) – Pressacco Oct 04 '16 at 12:48
  • Since you have changesets missing, how about creating a new branch? – Cece Dong - MSFT Oct 05 '16 at 01:21
  • Two development branches would be awkward: to view a file's history you would have to look in two places. And deleting the old branch would result in the changeset history being lost. – Pressacco Oct 05 '16 at 12:40
  • How about using Rollback? – Cece Dong - MSFT Oct 06 '16 at 01:45