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?
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.
Keeping the development branch history intact.
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.
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:
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.
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.
Related
Maybe its a confusing title but the scenario is this one - we have two branches; DEV -> QA. When tests are done people merge their changesets from DEV into QA one by one. All fine. The strange thing is that a small number of merged changesets are appearing in Merge wizard when we attempt to do reverse integration QA -> DEV. If I pick one for the merge, pending change shows that files are checked out with an 'merge,edit' tag but when compared to latest there are no differences.
Obviously we need to fix this since the list keeps getting longer and longer. But, I would like to understand why is this happening in the first place. Then, how to fix this situation.
We're using TFS 2015 server and Visual Studio 2015. No 3rd party tools.
Thank you for reading.
When you want to merge back, the changeset reappears is because when TFS does a merge, it bases the merge on prior merge history, not on the actual contents of the source and target files.
If you have such request, you can use tf merge /discard command to update the merge history, which does not perform the merge operation. This discards a changeset from being used for a particular merge.
https://learn.microsoft.com/en-us/azure/devops/repos/tfvc/merge-command?view=azure-devops
I'm using TFS 2010. I have 2 changesets in child branch that I do not want to merge in the parent branch.
e.g
(1002) Rolled back changeset
(1001) Changeset checked in by mistake
I don't want these changesets from appearing in the merge menu when you attempt to merge into the parent branch.
If I have understood correctly that I can use the following TFS command to ignore these 2 particular changesets or will the rollback changeset interfere?
tf merge childbranch parentbranch /r /version:1001~1002 /discard
You can do a discard
merge.
This has to be done from the command line. Open up the Developer
command
prompt,
then navigate to a folder under either of your branches (i.e. navigate
to one of the affected
workspaces).
Then type:
tf merge /r /discard "$/Project/B1" "$/Project/B2" /v:C12345~C12345
This will take the changeset identified (in this case it was changeset
#12345), and update it as merged to the target branch (branch B2). The target files will be checked out, but they will not be changed - you
can simply check them in to complete the operation. After that the
changeset will no longer appear as a merge candidate. You can specify
a range of changesets to merge at the same time, but they should be
contiguous.
Note that after doing this a changeset will occasionally still show up
as a merge candidate - this is rather uncommon with the latest
versions of TFS, and it is virtually impossible to fix (unless you are
running your own local install of TFS and want to get your hands very
dirty in the database). If you end up with one of these marooned
changesets, just ignore it.
Source:
Finding merge candidates in TFS
Note: When the command has finished, you still need to check in the merge.
For more tutorials, you could also refer below blogs:
TFS: Discard changesets when merging to branches
DISCARDING CHANGESETS IN TFS
So I fixed a bug on our main branch some months back, let's say some old changeset 555. Recently, I manually copied these changes to a child branch for a recently approved hotfix, changeset 999. I would like to do a Track Changeset on 999 and see this it has been merged to main as 555. But, I've done this backwards according to the TFS rules, you can't merge down to a child branch.
Is there a way to tell TFS "accept my old changeset 555 as the merge of 999 to the main branch"?
This is analogous to the ClearCase version tree workflow, using the "don't perform merge, just draw arrow". Thus the Track Changeset for either 555 or 999 would show that they are related.
I'm not sure what you mean by
But, I've done this backwards according to the TFS rules, you can't merge down to a child branch.
There shouldn't be anything preventing you merging this change to a child branch, you might have some merge conflicts to resolve. However if that really isn't a possibility and you want to merge "999" in to the main branch without actually merging the code (i.e. adjust the merge history) then you can using the tf merge command line.
Open a visual studio command prompt and use the command
tf merge $/TeamProject/childBranch $/TeamProject/MainBranch /version:C999~C999 /recursive /discard
This will tell TFS to update its history to say that the merge occured even though it hasn't. You might want to use the /preview switch before you do the merge "for real" to make sure you are discarding the files you expect.
I made a branch and the first time I went to merge from the source to the branch there were a whole bunch of old changesets coming up that it says were not merged but they were present well before the branch and I confirm that they were there.
Example:
Say I branched from Source to Target when there were 9 changesets in Source.
Change 10 was made in Source.
I go to merge from Source to Target and TFS tells me change 6 and 7 and 10 need to be merged (even though 6 and 7 were there before I branched and I can confirm those changes are in the Target)
I am new to TFS and this happened when I first started to implement Branching and Merging.
The newest branch I made did not do this.
Right now we have a Trunk and then 1 Branch for the ongoing QA for the next release and another Branch for the Hotfixes to Production. It was the QA branch that had this issue but when I made the hotfix branch it was fine.
I have come across this a few times. I eventually just merged the "rogue" candidate change-sets from source to target. I examined the pending merge and determined that there were no changes. Committing the merge got rid of these candidate change-sets. I figured that I could roll back if it didn't work out.
EDIT: It appears that if you upgraded to TFS 2010, there is a bug that will cause extra merge candidates (see http://support.microsoft.com/kb/2135068)
"Any items on a branch that have been renamed multiple times or have had multiple other items occupy their namespace (through add/delete combinations) will have lost their relationships with the corresponding items on other branches."
As for a resolution, the support article says:
"To resolve the issue with extra merge candidates, the /discard option should be used. To do this, run a merge of the following format from a command line:
tf merge <source branch> <target branch> /r /discard:CXXX~CYYY
In this example, XXX and YYY represent the changeset IDs of the range of changes to discard. After this merge has been checked in, the unwanted candidates will no longer appear for future merges. Also be aware that, because of improvements in the merge algorithm in TFS 2010, items deleted in both the source and target branches will result in changes to be merged. In those cases, it is best not to discard the changesets so that the merge history is updated correctly. "
I've had this a few times too. I suspect the cause is some funnyness in the way TFS manages pending merges. If you try to merge these changes, and the Change type is just "merge" and not "merge, edit", then it is safe to merge them and be confident that no changes have occurred. If you don't merge them, TFS will keep trying to merge the non-changes indefinitely, possibly obscuring real changes eventually. I advise merging these non-changes ASAP.
I am merging my development branch into the main branch. There is only a subset of files that I have changed in my development branch, all other files should remain unchanged. Logically, I only want to merge files which I've changed. I would not check in a file which I did not change.
But when I do the merge operation in TFS, it marks every single file in the tree with change type 'merge'. It looks like I must checkin every single file in the whole source code tree! I really do not want to do this becasue then it becomes impossible to look at the changeset and see what files I acctually changed as part of my project.
At first, I thought I could use the tfpt.exe Undo Unchanged command to undo all the 'merge' changes, but this won't undo those changes.
Anyone have any ideas on this? thanks.
This also happens with a baseless merge. A baseless merge occurs when TFS doesn't have an existing merge relationship between the branches you're merging. As a result, it considers every file 'new' in both branches, so it 'merges' every file.
To create a merge relationship, so that future merges only list the files that you've actually changed, you need to do a baseless merge of all changes up to a specified version so that TFS knows what the common baseline should be. You should do this after merging these changes - it's too late to correct the baseline for this branch now.
If you don't actually want to take any changes from the other branch, but just tell TFS that these are logically at the same version, you can do a merge 'giving credit' for the changesets: tf merge /discard.
There are a number of possible reasons. This is not a complete list:
You performed a namespace operation (delete, undelete, rename) on a parent folder of the
files marked "merge"
You performed a namespace operation (delete, undelete, rename) that had already been performed in the target branch
You performed a sequence of namespace operations that collapsed into a no-op (eg delete + undelete, or rename a -> b -> a)
There are unresolved conflicts
You performing a discard
Note: all of these apply equally to 2005 & 2008.
In Visual Studio 2008 and TFS 2008, this does not occur. Only files that have changed will be marked as merge. If you do a compare of a file between the branch and the trunk are there any changes? Changes such as encoding will still make TFS merge this file back.