So, we have our main dev line, I create a branch, and developer b creates a branch. We both do some work. developer b finishes his work, merges back into the main dev line. I know his changes will affect me, and rather than deal with the conflicts later, I would like to update my branch, with the changes that are now in the main dev line, so I can deal with them in my branch, prior to merging back into main.
How do I do that?
From Visual Studio, open Source Control Explorer:
View | Team Explorer
Select your Team Project from Team Explorer, expand it, and double click Source Control
In the left-hand pane of Source Control Explorer, select your Team Project.
In the right-hand pane, find your mainline branch, right-click and select Merge...
In the Target branch drop-down, select your dev branch.
If you want a subset of all the changes in the mainline:
Choose the Selected changesets radio button, click Next.
Select the changesets that represent the merge from your other dev's branch into main, click Next.
Otherwise, keep All changes up to a specific version selected, click Next
The next step has you pick a Version type. The default, Latest Version is obviously straightforward and self-explanatory: you would be brining all changes since your branch was created from the mainline down into your branch. The other choices are straightforward, but a tutorial explanation of each option available here would take a fair amount of space.
Walk through the remaining steps of the wizard.
Click Finish.
If there are any errors or merge conflicts, you will be prompted to resolve them, similar to what you would see if checking your changes into source control when other changes had been made since last checkout.
After the merge is done, all the changes are in your local copy of the branch, but they are not yet committed to source control. Once you've completed all your builds and testing on your branch, you can check in the merge. From Visual Studio:
View | Other WIndows | Pending Changes
Make sure all the files related to this merge are checked, add comments describing the merge, and click Check In.
I recommend keeping merges (and any necessary merge conflict resolution, build breaks, test breaks) as their own changeset. That is, do not mix other feature work with merges. Granular changesets make it much easier to review source control history, and to identify a single change of interest. Keeping merge work in its own changeset helps work toward that goal.
There is command-line for merging as well, run tf merge /? from a Visual Studio Command Prompt.
Related
We had some changes committed (let's call it changeset1) in what we call the Dev branch of our project that really should've been done in a new branch. So what I did to fix it is create a new branch off of the Dev branch (let's call it Dev2). Then I rolled back the Dev branch to before changeset1. So now the code base looks like the development was done in Dev2 and Dev was never touched.
Later, I then did some development in Dev, merged it to Stage, and then Prod. Now I'm trying to also merge those changes into Dev2 but when I perform the merge (in VS 2017) it auto-merges everything and it wants to delete all of the changes from changeset1. I guess because I rolled back Dev after changeset1, it sees that as the latest change and wants to merge that rollback to Dev2. How can I get it to see Dev2 as the latest and merge my new Dev changes into it without deleting changeset1's changes?
For clarification, Dev is the parent of both the Stage and Dev2 branches.
According to your description, seems the merge process didn't pick up the rollback changeset1 in Dev branch, which cause this scenario.
This is caused you didn't use /keepmergehistory option during your rollback.
tf rollback /keepmergehistory
This option has an effect only if one or more of the changesets that
you are rolling back include a branch or merge change. Specify this
option if you want future merges between the same source and the same
target to exclude the changes that you are rolling back.
Please go through the detail explanation and some examples in our official tutorial here: Example: /keepmergehistory Option
Besides, you could also take a look at this similar question: TFS merge doesn't pick up rollback changeset(s)
I figured out a way to resolve it. So to re-iterate, I think the problem was the changes I wanted were in Dev2, but I rolled back Dev after creating Dev2 so the rollback was the most recent change so the merge wanted to keep the rollback and delete the changes I wanted to keep from Dev2. So I came to the conclusion that what I need to do was somehow apply those changes to Dev2 again as if they were a new edit.
So what I did is:
Move the changes from changeset1 into a Shelveset
Merge Dev to Dev2, thereby deleting the desired changes
Unshelve the changeset1 Shelveset to Dev2
#1 was the hardest part. First I created two new workspaces: DevC0 and DevC1. I pulled the changeset from before changeset1 into DevC0 and pulled changeset1 into DevC1. So now DevC1 has all the changes I'm interested in and DevC0 does not. I then copied all of the changed files (using BeyondCompare but I think you could just copy all your files except for the TFS folders/files too) from DevC1 to DevC0. Then at the command line, I did a tf vc reconcile on the DevC0 folder to allow it to recognize all the changes I just copied over. E.G. (I didn't actually want /deletes in my case):
tf vc /reconcile /promote /adds /deletes /diff /recursive [DevC0 itemspec]
(Make sure your command prompt's working directory is a directory mapped to your target workspace). After that, all of the differences now appear as pending changes in Visual Studio Team Explorer/Source Control Explorer. So from there I can create a Shelveset.
#2 was just a typical merge from Dev to Dev2. It deleted all of the changes and made Dev2 match Dev. I don't know if I needed to check this in before applying the Shelveset but I did.
#3 My changeset1 changes are in my Shelveset, but the Shelveset belongs to the Dev branch. Luckily, Team Foundation Power Tools can unshelve a Shelveset to a different branch. E.G:
tfpt unshelve /migrate /source:"[Dev server path]" /target:"[Dev2 server path]"
This opened a window with merge options for each file. I manually reviewed the first few then tried auto-merging all. That did the equivalent of what merging via Visual Studio does - it auto merged where possible and left the conflicts up to me in that same window. After that, it appeared all of the desired changes were now pending changes in Dev2 and I checked them in.
I then tried a merge from Dev2 back to Dev just to see if it was going to behave correctly and it did merge all of the changes to Dev and marked many of the changes that were deleted by the original rollback as undeleted. For now, I undid pending changes from that merge until we are actually ready to merge this sub-branch of work into our main Dev branch.
We have a TFS branch structure like Main > Integration > Several Branches under this.
The problem is that I created a folder 'feat-IIS6toIIS7Migration'outside the above hierarchy when I started coding. After finishing coding I converted the folder to a branch.
But the new branch has no parent and I want to put it under Integration. It seems that its impossible to do this in TFS, since when I try to re-parent I get an empty list of possible parents. Is there a way to put the new branch under Integration?
If you want the folder to appear under the integration branch then you can just move it (right click in Source Control explorer and select move).
$/Root/Integration
$/Root/feat-IIS6toIIS7Migration
becomes
$/Root/Integration/feat-IIS6toIIS7Migration
When the integration branch gets merged with either main or your development branches the folder will be added to those branches as part of the merge.
If you want to give the feat-IIS6toIIS7Migration folder a branching relationship with integration then you need to perform a baseless merge. Note you should only do this if the feat-IIS6toIIS7Migration folder is a full replication of the integration branch.
In TFS / VS 2012 you can perform a baseless merge from the GUI.
Right click on the integration branch in Source control explorer and
select merge. This will be your source branch.
In the target branch dropdown you won't be able to see the
feat-IIS6toIIS7Migration folder.
Select "Browse" and then navigate to the location of the
'feat-IIS6toIIS7Migration' folder.
Keep hitting next until VS performs the merge.
I would expect there to be a fair few merge conflicts and you'll need to resolve a lot of them manually.
In the future it would be better to create the branch for your development before you start work, then you can take regular merges so you don't have a big merge at the end of your development.
Using VS2013 and/or VisualStudio.com, is it possible after creating a branch ("Main" branched to "Dev001") to view a list of all the files that differ between "Main" and "Dev001"?
For example, I'd like to see all the files that have been amended/created within the current branch, since it was branched.
The closest I have got is right-clicking the branch, selecting View History, then clicking each changeset to view the files in the Changeset Details panel, however, there are many changesets in there which is taking a long time.
Please note I am not using Git.
Just right click on your Main branch in Source Control Explorer an select Compare.... From there you can specify the path to your branch and the versions you would like to compare.
We've had this happen more than a few times were we consider it to be more than a fluke at this point. When we are merging back after we are complete with our branch there are way more changes then their should be. So most of the files showing as pending changes never changed (in most of the cases in neither the branch or the base). When i compare them (i use beyond compare) there are no differences. I haven't went through all the files that didn't change but in most cases it seems like they are marked as [merge] and the files that actually changed are marked as [merge,edit].
In one case we probably changed around a 100 files it pending changes showed more than 22,000 changes. We tried checking them in at one point thinking tfs would be smart enough to know what files changed and which didn't. But it checked in all files. Does anyone know whats going on and how to fix it?
We are running TFS 2012 w\ Update1
Everyone is using Visual Studio 2012 w\ Update 1.
For anyone having the same issue a work around is to undo your pending changes. When you get the confirmation dialog choose "No to all". Only your pending changes should be left.
Regarding the problem where you had changed 100 files and TFS wanted to merge several thousand. This is usually caused by renaming (or deleting and then un-deleting, or moving) a branch. This has bitten me a couple of times and I feel your pain.
The best advise I can give is, once you've created a branch, leave it alone. Don't move it, don't rename it. If the location or name of the branch are wrong, live with it until it's time to delete the branch and create a new one.
Because of the way TFS 201x work behind the scenes, changing the root folder of a branch effectively turns it in to a different object. When you try to merge the branch again, TFS will perform a baseless merge which effectively means that it appears that all files in the branch have changed (even though they haven't) This is new behaviour, older versions of TFS (2005 / 2008) don't suffer from this problem.
e.g. you have a Team Project that looks like this
$/TeamProject/Main
You then create a branch from "Main" called "Dev"
$/TeamProject/Dev
You can merge as much as you like and there shouldn't be any problems. Then you decide that the folder structure might get a bit messy when you have several dev branches so you create a folder called "Development" at the root of the team project and move the dev branch in to this folder
$/TeamProject/Development/Dev
OK now behind the scenes the move is a rename and a delete, the old dev branch still exists under $/TeamProject/Dev (you can see this by going to "tools", "options", "Source Control", "Team Foundation Server" and then check the setting that says "show deleted items in Source Control"
The folder called $/TeamProject/Development/Dev is actually a brand new thing! Therefore it doesn't have a merge relationship with "Main". Confusingly though the IDE will show a relationship, but really it doesn't exist. The first time you merge from $/TeamProject/Development/Devto $/TeamProject/Main TFS will perform a sneaky baseless merge to establish the branching relationship.
The same thing happens if you rename a branch (the old branch will be deleted and a new branch will be created under the covers)
This Blog goes in to some more detail
The comment above with the "No to all" option in the undo confirmation dialog works okay, but as commented by Mark Hosang, this will not work right if you have new files. Mladen Mihajlovic is right that you can make sure to not select those new files. However with a large code base, wading through this is very tedious.
So my method: before getting to the confirmation dialog, you are presented with a window to select which files to undo. This window has sortable columns. You can sort by the Change column and select only the files with merge status (these are the unchanged files; merge, edit are edited files and merge, branch are new files). Just click Undo Changes with just those selected, and then enjoy the beauty of an uncluttered merge changeset.
Try this:
select all pending files
on context menu click 'Undo...'
in the 'Undo Pending Changes' dialog sort files by 'Change' column
deselect all files except 'merge' using shift+click
click button 'Undo Changes'
From my experience this happens when TFS has no relationship between file A in branch A and file B in branch B.
When merging branches TFS always creates a relationship between the files when no relationship is present already. Hence it wants to check in as "merge" to remember these relationships.
I tend to undo these "merge" changes when i don't need the relationships (e.g. for reparenting).
We have a setup with a development "trunk" in our recently-migrated-to-from-VSS TFS system and developers have been doing work in branches off the trunk, which are merged back in.
We've been diligently commenting our changesets at check in time, something we never did in the VSS days. However when I right-click on a trunk file in the Source Control Explorer and choose History, I only see monolithic changesets labeled "merge from dev branch" (or whatever the developer scribbled in there when they merged.) A history entry doesn't even seem to contain info on which branch was merged in at that time, let alone any info about the changesets that make it up, or the comments that go with them.
How have other TFS users dealt with this issue?
Is there another way to view the history that I'm missing here?
Looking at the history of a change prior to the merge has been a bit of a pain point with TFS. So much so that Microsoft have done a lot of work to address this in the next version of TFS (TFS 2010). In TFS 2010 (when it comes out), when you get to a merge in the history view it is actually a little twistie that you can expand and go see the history for the thing that was merged which is much nicer.
In the meantime, when I see I big monolithic merge (or branch) comment I tend to let out a audible sigh and then go find the file in the branch it was merged from in Source Control Explorer and do a view history there.
This might be what you are looking for: http://www.codeplex.com/TFSBranchHistory
Haven't used it personally, so I can't vouch for it.
Visit "TFS Branched History" plugin page at Microsoft Gallery:
http://visualstudiogallery.msdn.microsoft.com/7d4f37b6-f9a4-44c6-b0a0-994956538a44
Plugin does insert "Branched History" button into the context menu of Source Control Explorer (TFS)
The button icon is with clock like standard "History" but with blue arrow:
If you click "Branched History", new window will be opened and Path property will be set to the current Source Control Explorer path:
Click "Run query" to get results at the "History" tab:
From context menu you can query standard Changeset Details and Compare File (Folder) dialogs.