Here is my scenario:
I did a merge from branch-A (source) to branch-B (target). That merge carried out pending changes in branch-B that I had to check-in (e.g. changeset 1000). Then I built and published branch-B in Test environment in order to test it and I realized something was going wrong. I thought the culprit was being the merge so I decided to roll back the previous merge (changeset 1000). This roll back carried out pending changes that I had to check-in them again (changeset 1001) into branch-B. Now after investigating a lot I have discovered that the merge (changeset 1000) was not the culprit so now I want to undo the roll back of the merge (changeset 1001) and return to changeset 1000. Below and example.
branch-B history:
changeset 999 - Initial
changeset 1000 - Merge source (branch-A) to target (branch-B)
changeset 1001 - Roll back previous merge to return to changeset 999
How can I undo changeset 1001 and return to changeset 1000, I mean, restore branch to changeset 1000? By reverting to changeset 1000 and then check pending changes in again?
Some information about rollback in TFS, please kindly refer below:
If your change is still pending (you have not yet checked it in),
you can undo the change instead of rolling it back. See Develop
code and manage pending changes.
Like most changes you make to files, a rollback change is queued as a
pending change. After you roll back the files, you can view the files
you are changing and compare the content of the files with the latest
version on the server. After you confirm the actual changes match
what you intend to do, you can then check them in.
Rollback does not delete changesets or any data. If you change your
mind, use rollback to revert the content of the files back to their state before the rollback.
Hope this helps.
Related
I need to merge a changeset to another branch in TFS. But unfortunately, due to an unwanted code checkin happened in this changeset, I cannot merge the full changeset to the new branch. Therefore I need to skip the unwanted files from the changeset and merge other files to the new branch. Is there are a possibility of doing that? Ps: Since the changeset is huge I cannot merge it manually.
You can do this, what you are going to achieve kind like a partial merge.
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
So, if your unwanted code only exist single or few files, you could follow scenario 1, undo those files.
If those files sill contain some other need changes, then I would suggest you directly merge all changes and create a new changeset after merge operation to exclude those unwanted code.
This should be the simplest solution.
I am looking for a way to discard some unwanted change sets using TFS. I have looked into this site and many other and know that we need to use
tf merge /version:C137~C137 branch1 branch2 /recursive
However, I store all my source code in TFS DEV environment, I normally check out the code from DEV to my machine, work on it then check it back in DEV, roll back, fix it then check it back in. This process create many different change sets that hang around and needed to be cleaned up. So when I use TF merge command which branch I have to specify DEV and ????.
Thanks for your help
The merge command applies changes from one branch into another. /discard option means does not perform the merge operation, but updates the merge history to track that the merge occurred. This discards a changeset from being used for a particular merge.
But according to your description, you don't use branches or merge. What you want is delete/destroy changesets. Unfortunately, you can't delete changesets in TFS by default, if you delete changesets, the version control may be defeated.
You can always work with the latest version, when you want to work on a specific version, you can use TF rollback command. This command does not remove the changesets from an item's version history. Instead, this command creates in your workspace a set of pending changes that negate the effects of the changesets that you specify.
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
Suppose you realized that you forgot to checkin just one file during a tfs checkin.
Is there a way to rollback the checkin, have the changes that were part of it show up as pending changes and just add the incremental file change. And then just check everything back in.
The reason for my weird request is as follows.
Suppose you do two separate checkins. But those checkins are not successive checkins in the folder/solutions history.
Then when i need to merge just my changes to parent branches, I need to do separate merges for each checkin in the child branch.
Annoyingly tfs doesnt allow non-contiguous checkin. And if the parents branches are gated ie they build each time after checkin, it can mean a wait time of 10 minutes per changeset/checkin. Aarghhhhhhhhhh
Rollback the original changeset
Checkin
Rollback the rollback
Add in the change you forgot the first time
Checkin
If a file has been changed by 10 different changesets, with different users for various changesets.
Then the user that checked in changeset 5, decides to merge his changes.
What will then happen to the changes in changeset 1 to 4? Will they automatically be merged?
TFS has two ways of merging (you can select either one in the TFS Merge dialog):
All changes up to a specific version
Selected change sets
In the second case, you can cherry-pick any change you want, without necessarily merging all other change sets.
Yes, TFS will merge all changes UP TO and INCLUDING changeset 5 automatically.
When you merge a particular changeset back to Main, you are effectively asking TFS to integrate all changes beginning from the previous baseline up to the changeset that you specify.