I checked in commit 100 last night on our trunk. Another developer checked in commit 101 this afternoon on the trunk. I wished for him to create a branch instead. What is the easiest way to revert the trunk back to 100 and to create a new branch that contains 101?
Create the branch now from 101. Once the new branch exists use the rollback command to undo 101 in trunk.
If you are using TFS 2012 you just need to view history of trunk and then highlight checkin 101 and select rollback complete changeset. Checkin the rollback, this will be checkin 102.
You may have problems when you come to merge the new branch back to trunk, if TFS thinks the rollback takes precedence (because its more recent) then use a visual studio command line to do the merge and use tf merge $/teamproject/devbranch $/teamproject/trunk /recursive /force
Related
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 have checked out from the main trunk and made some changes that I do not want to go back into the main trunk. If I create a branch in TFS after I have already checked out the code, how do I check my code into the new branch that did not exist when I originally checked out the code?
You need to shelve your changes and then unshelve it into another branch
I have some changesets in a TFS 2008 branch which were not merged back into trunk. Time has passed, and now no-one is entirely sure which changesets have made it into trunk. I understand that TFS 2010 allows you to see graphically which branches a changeset has been merged to, but how can I find this out in TFS 2008?
I think all you can you do is use the TF merge command to determine which changesets have not been merged into another branch - one branch at a time.
tf merge /recursive /format:brief /candidate $/Branch1 $/Branch2 /preview
will show you what changessets from branch1 are candidates to be merged into branch 2. Of course you can put this into a script to run multiple times.
Is it possible overwrite a branch with another?
Or is the only solution to delete branch B and make a new branch from Branch A?
Unless you're running TFS 2010, I'd recommend using Merge + Resolve to bring the two branches back in sync.
# cancel out of conflict dialog
tf merge A B -r -force -version:T
tf resolve B -r -auto:acceptTheirs
That should equalize everything, except for files that were only created in B and never merged back. Use Folder Diff to find & reconcile them.
Delete + rebranch in 2005/2008 runs the risk of nightmarish-to-debug namespace conflicts in the future. The other option, if you have 2008, is to Destroy + rebranch. Obviously that assumes you are ok with losing all the history from the original copy of B.
In Visual Studio 2010, I just used the baseless merge to achieve this:
Tf merge /baseless [source path] [target path] /recursive
When the resolve conflicts window popup, select 'Take source version' option. Note, the files only exist in target will not be deleted by using baseless merge, but you can compare the 2 branches to identify the difference and delete them manually.
Refer to: http://msdn.microsoft.com/en-us/library/bb668976.aspx
I had success using Richard Berg's answer but felt like there were a few details that were missing. This is how I was able to eliminate differences related to conflict resolutions and changesets that had not been merged back to the source and make the target identical to the source. Note that this is how I will be referring to the branches - source is the one that should not be changed while target is the one that should be made identical to source.
Make sure that you have the latest version of both the source and target branches in your workspace. Also make sure that you do not have any pending changes.
Discard all of the candidates for merges from the target branch to the source branch. This is to prevent any of these differences from being unintentionally merged back into the source branch later on.
tf merge $/target $/source /recursive /discard
Note: Make sure that you have set the working folder to a path within your workspace so that the tf tool knows which workspace and TFS server to use.
Check that there are differences between the branches that should be addressed - if not, no further action is required.
3.1. View history on the target branch and find the last complete merge from the source to the target (ignore any cherry picking merges as that will result in lots of false positives) - note the changeset number. An easier alternative would be to perform a merge from the source branch into the target branch to get the lastest version from the source branch into the target branch.
3.2. Right click on the source branch in the Source Control Explorer and select Compare from the context menu. Only take the latest version for the source if you merged the source branch into the target branch in step 2.1. Otherwise select Changeset from the Source Version | Type combo box and then enter the changeset number from step 2.1.
3.3. Use the drop down arrow on the Browse button next to the Target Path field to select Server Path. Then select the target branch in the dialog that opens.
3.4. Click OK on the Compare dialog to perform the comparison.
Perform a merge from the source branch to the target branch and pass the force option. This will ignore the merge history and merge changesets even if they have been merged in the past.
tf merge $/source $/target /recursive /force /version:T
Note: the T version specification indicates the latest version.
Close the merge conflicts dialog.
Automatically resolve all conflicts by choosing the source branch.
tf resolve $/target /recursive -auto:TakeTheirs
Check in.
Confirm that there are no longer any candidates for merges from the target to the source and that there are no differences between the two branches (this time just using the latest versions as we did a forced merge of the latest version in step 4.).
See MSDN for more details on the tf merge and resolve commands.
Delete the branch B and create a new one from branch A.
Is there a reason why you do not want to do this?