Ignoring 2 changesets - tfs

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

Related

TFS Create branches from Main - selected changeset

I have an issue; we have a Main branch, and we have few changesets (that belong to 3 different features).
I created three DEV branches By Date (and selected a date that is prior any of the changesets).
I cherry picked the changesets from Main, and merged them to appropriate DEV branches.
I RolledBack all these changesets from Main so that, the main becomes clean.
Now I want to merge one of DEV branch to Main and deploy for testing,
The problem is; it doesn't pick all the changesets, and even for the ones that it picks, it doesn't pick all the modified files.
How can I merge from DEV to Main? Please help.
Thanks
When TFS does a merge, it bases the merge on prior merge history, not on the actual contents of the source and target files.
You could try the /force option with the tf merge command. The /force flag ignores merge history that indicates a particular changeset was previously merged from source to target (perhaps incorrectly), and merges the changeset again. You can do a /force merge for a single changeset or for a range of changesets. For just changeset #123456 the command would be:
tf merge /force $/Source/File.cs;C123456~123456 $/Target/file.cs
Check the following blog for more details:
https://blogs.msdn.microsoft.com/billheys/2011/03/16/my-source-and-target-files-are-different-but-merge-tells-me-there-are-no-changes-to-merge/

HowTo: correctly synchronize TFS branches with missing changesets?

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.

How can I resolve a partially merged changeset in TFS?

One of my projects in TFS keeps displaying changesets as unmerged between the branches after I have already merged and committed them. I used the Track Changeset feature and clicked the Visualize button to see if the change was merged. It shows that it was merged but has a different background color and an asterisk. I checked the help and it gives this explanation:
If a branch has received some (but not all) of the changes in a changeset, the branch is filled with a pattern, and an asterisk follows the changeset numbers within that branch. For example, the previous illustration shows that only some of the changes in changeset 38 were merged to the Test branch
Track Changes Help
I don't understand how it is that I only partially merged those changesets. Perhaps I did not have latest when I completed the merge but it is happening to a lot of the changesets and this only happens on this one branched project folder.
Is there a way to find out what did not get merged and merge it so that the changesets will quit showing up as a merge candidate?
A partial merge is recorded when only some changes from a changeset are merged into the target. There are two common scenarios in below which you can end up with partial merges:
Scenario 1:Undo some pending changes when you are checking the merged files
In this case, even though we already merged changeset Dev to Main, it is still a merge candidate. This is caused by the fact that the merge engine detected that there are still some changes in that changeset which were not propagated from Dev to Main.
Scenario 2: Performed the merge at feature level not from the top of the branch
For example: consider that you have two branches Main and Dev, each of them has two folders (Feature1 and Feature2) and each feature folder contains one file. We edit both files from the feature folders (Dev\Feature1\feature1.txt and Dev\Feature2\feature2.txt) and check-in the changes.
If you perform the merge operation at the Feature1 level.(Changset142→
Changeset143) You will notice in the Pending Changes window that only the edit done in the Feature1 folder will be merged. Complete the merge.
If you take a look at the merge history of the Feature1 folder you will see that all changes from changeset 142 have been merged into changeset 143.
However,if you take a look at the merge history of Main you will see that only parts of changeset 142 have been merged into changeset 143. This is normal as changeset 142 has some changes – the edit of the file in the Feature2 folder – which were not delivered.
In case of a partial merge, to figure out what changes have been merged and what changes from the changeset were left out. The only way to achieve this is to diff the contents of the changeset that was partially merged, and the contents of the changeset that was generated as the result of the merge. More detail info you can refer this blog: Partial Merges in TFS – A Guide
Update
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

TFS 2010: Remove changesets to be merged

In TFS 2010, when I want to merge files from one branch to another, I get a list of changesets that are yet to be merged to the target branch. The problem is a lot of these changesets have already been manually merged. So I am getting a lot of 'There were no changes to merge.' messages.
So I need to remove those changesets ( which have already been merged, i.e. no changes to merge) from the total list of changesets that are to be merged with the target branch. Please suggest a way to do this as I am new to TFS.
You should always be meeting the latest, or everything up to a specific changeset.
http://nakedalm.com/avoid-pick-n-mix-branching-anti-pattern/
Picking and choosing changesets to merge is not a good way to manage your code.
To unblock your merge you will need to discard the merger candidates that are no longer relevant.
tf merge /discard

Is there a way to associate a new TFS changeset with an old changeset?

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.

Resources