I have my "Main" branch from where I branched and created a new "Release" branch. In release we then checked in a few items, and then we were ready to merge back to the "Main" branch, but when I do this I get a changeset containing ALL FILES, why is that? What am I doing wrong? I am only interested in merging what has changed since the branch obviously.
When you merge in Merge wizard in Visual Studio, please choose Select
Changesets not choosing All changes up to a specific version. By default it is at All changes up to a specific version.
Then it list those changsets that haven't merged to the Main branch. You could select the latest changesets to merge.
Related
We are having problems trying to do a merge using Team Foundation Version Control from Visual Studio 2017, and we don´t know if it´s posible or even sensible to do it as we want to.
I am going to explain a simplified version of my problem:
We have a root branch in Source Control, let´s call it Root, and we have a branch of Root that I will call Branch.
We are commiting changes to Branch and when we are sure we want them on Root we Merge from Branch to Root (we do a Reverse Integration). Thing is, we did some merge in the past where we selected only a subset of the Changesets in Branch to merge them into Root.
Now, after some other changes in Branch, we know that the latest version we have of Branch is working and we want to merge that version into Root.
The problem is that when we are doing the merge, it takes the version of a file as it was on the last changeset that modified that file AND that changeset was not merged into Root. But we know that the last version of that file in Branch is the version we want, even though it doesn´t appear because the changeset that let it in that state could have been previously merged (in fact, most of the tiemes, the last version of that file in Branch and Root are identical, and we don´t want change that).
Example:
We make Changeset 1 into Branch and we merge it to Root.
We make Changeset 2 into Branch, modifying File1 (but we don´t merge it into Root).
We make Changeset 3 into Branch, modifying File1 again, and we merge it into Root. Now Branch and Root have the same version of File.
We make Changeset 4, 5, 6 into Branch, unrelated to File1.
Now what we want to do is merge the latest version of any file AS IT IS NOW in Branch, into Root.
But if I try to merge Branch into Root, it will prompt that there is a conflict, and what it will show in the Conflict Resolver is:
File1 as it was after Changeset 2 as the source (that is the version of the file as it was after the last Changeset not merged into Root), and
File1 as it is in the Root as the target (and that happens to be the exact same version of the File1 that I have in the last version of Branch, and I want to keep that way).
By the way, it doesn´t matter if we mark "Select all changes up to..." with Latest Version, Changeset (using the latest), Date (now), Workspace, etc.. or "Selected changesets" and then we select everything (of course, previously merged ones doesn´t appear here anyway).
Is that some way to tell Source Control that we want to merge the latest version of every file in Branch into Root, regardless of wether the changeset was previously merged or not? Does all this makes any sense at all or am I missing something?
The TFS merge engine relies on history, not file contents. You may check tf merge /candidate command to list the changesets in the source that have not yet been merged into the destination. And use tf merge /version to merge the changes. Check the link below:
https://learn.microsoft.com/en-us/azure/devops/repos/tfvc/merge-command?view=azure-devops
By the way, there will always have situation that you have to manually merge.
We have very large project and we have to branch some of the sources. Branched sources should be stored in a different location (within the same TFS server).
The problem is that due to active development of the main project we have to merge changes from trunk every day.
So the question is: how should I branch sources to provide the easiest merging from trunk.
The desired scenario is:
pull changes from trunk. Resolve conflicts and merge changed sources.
push merged changes to branch (that is stored in different location - not as a branched version in the same location)
Is this possible without any complex scripts?
I am using Visual Studio 2013 for work with TFS source control.
You can have branch relationships been different locations in TFVC. You can branch from one team project to another and maintain the relationship.
If you currently have two locations that do not have a branch relationship you need to create one by doing a baseless merge first. One you have some a baseless merge you can then merge s normal As if they are in the same team project.
I would however recommend that you fix the problem that has lead to this situation. If you are going a single product then you should all be in the same team project.
http://nakedalm.com/one-team-project/
I am using TFS2012 express. I have a project which has two branches.These two branches have similar file and code. Actually one is release code(one which i gave to customers) and another is testing code. I always change code in testing code branch. So sometime i need to checkin this changes to both the branch. Also some changes i don't want to check-in to both and only to testing code branch. So how i can do it in tfs? Problem is how to checkin only certain changes to both branch and some changes to only one branch?
You can always check in the changes to testing branch. If you need certain changes in the release branch as well, you can use Merge command to do that.
When you do Merge, you can choose "Selected change sets" instead of All changes. When resolving conflicts in mergetool, you can choose/make the changes you like in the result panel at the bottom which is editable.
When we create a branch from our main trunk in TFS we also change the web.config to point to different databases, web services, etc. When we make a bug fix we do it in the release branch and merge back to the trunk. I'd like a way to click on the root node for the branch and merge the whole thing back to the trunk except for the web.config which has release-branch-specific settings which should not be merged back.
Is there a way to break the branch link for this file or is there some other method to permanently exclude the release web.config when merging back to the trunk?
You have two options to do this today:
Use "tf merge /discard". When performed on a file across branches it tells the merge engine that you do not want this specific change merged between these two branches. The downside of this approach is that you will need to run tf merge /discard each time you check in a change to the file. Here is what the syntax would look like if you wanted to discard the change from moving from releasebranch to trunk:
tf merge $/releasebranch/.../web.config $/trunk/.../web.config /discard
The second option is to cloak the web.config in the target branch when you are performing the merge. That is if you are merging into trunk, cloak the web.config file in the trunk branch in your workspace. When you perform the merge, since the target of the merge is cloaked, the change will not flow over the branch. The downside here of course is that you have to remember to perform the merges in workspaces with this configuration each time.
Bonus: I created this uservoice suggestion to improve this experience. Vote for it if this is something you would like to see improved.
s/w versions:
TFS2008 server, VS2010, windows xp
I have the following branch structure in TFS
$/Root/Main Branch
$/Root/Dev/Project1
Project1 was branched off the Main Branch, few months ago. Now I need to merge the latest code in the Main Branch to the Project1 branch. During that time, some new folders were added to the Main Branch.(Main Branch/CoreDataClasses/..). So when I try to merge this new folder into the Project1 branch using the merge wizard, I don't see the Project1 branch in the list of target branches. Why is TFS not showing me my dev branch in the target branches list?
Do your merge from the root (where you branched), not the individual folder(s). Remember that merges aren't destructive until you check in, so you can choose to only check in the new folders if you want to hold off other changes.
With Tfs I've had much better experience merging from branch to the trunk and I think this might be the case here. Of course this might take a rethink of your strategy but it's doable.
I know this may be way offside but if you're doing cross branch merging a lot then definitely consider a distributed version control system like mercurial. I've used Tfs lots and really like it but when it comes to branching and merging it is a distant second to hg merge (mercurial command)
The folder structure between source and target have to be the at least 80% the same. If there was too many restructuring of the folder layout then I suggest you use the cmd line Merge with the force switch when doing the merge. See "Merge Command".