I moved from Subversion to Microsoft's Team Foundation Server for version control, and it is my understanding that you cannot merge discontinuous change-sets in TFS.
For example, I have a file called "baseline.txt" that looks like this:
line one
Then, I branch the file to a new file called "branch.txt", and then do two check-ins on "baseline.txt" so that it finally looks like this:
line one
line two //checked-in change-set A
line three //checked in change-set B
Now, I want to merge only change-set B into "branch.txt". In other words, I expect "branch.txt" to look like this after the merge:
line one
line three //checked in change-set B
Basically, I want to skip change-set A and merge change-set B. It is possible in Subversion, but in TFS if I want to get changeset-B, I have to also get all change-sets "up-to" B.
Is this true? That's what my experiments show, but "Understanding ChangeSets and Merge with Team Foundation Server" seems to indicate differently.
That article is confusing, and I don't believe it is accurate. When the second change is checked in, it should generate a merge conflict. At that time, you would need to resolve the conflict in one of three ways:
Merge the changes
Overwrite with the new changeset, or
Keep the old, and discard the new changes.
No matter what, when you get ready to merge back to baseline.txt, you have a "point-in-time" version of the file that you're going to check in.
Related
You see 162489 and 162990, How can I merge them ?
I'm guessing that you want to merge only those two specific changesets into another branch.
You cannot merge multiple changesets in one go, unless the changesets are in sequence.
Using the tf command line tool you specify a range of versions by separating the version with a tilde character.
tf merge /recursive /version:C162489~C162990 "$/SourceBranch" "$/TargetBranch"
In this case the changes 162987 and 162967 will also be included.
If you are using the UI in Visual Studio then the merge dialog will prevent you to select multiple individual changesets unless they are in sequence.
To merge two separate changesets into another branch you will have to do it in two steps:
merge 162489 and then 162990 (start with merging the oldest changeset in case both changesets contain changes to the same files).
Then your workspace for the target branch will contain the changes for both changesets and now you can check-in the merges as one changeset in the target branch.
In the TFS Merge help - http://msdn.microsoft.com/en-us/library/bd6dxhfy(v=VS.100).aspx
-, you see in the 2nd example how you can merge one changeset:
tf merge /version:C137~C137 branch1 branch2 /recursive
Is that what you are after?
Try this
tf merge /recursive /version:C162489~C162489 "$/SourceBranch" "$/TargetBranch"
tf merge /recursive /version:C162990~C162990 "$/SourceBranch" "$/TargetBranch"
If you don't have a conflict code change in these changeset TFS 2010 will merge consecutive merges.
Merge must be done in successive manner. In your case merging two changesets that are not successive is not safe because you can loose changes that could be done to the same files. That is why TFS client does not allow you to do that.
We have a tricky situation with our branches on TFS 2012 and now we are not exactly sure what will be the result of our actions.
The problematic branch structure is as follows:
/B----2-------
/
A -------1-----------
\
\C---3--
The pseudo diagram is approximately time-correct - at first branch B was branched from A and then later branch C was created. The numbers are the changesets in question (actually our problem involves multiple changesets on each branch, but I've simplified the diagram).
We wanted to merge changeset 3 from C into branch B. Visual Studio warned us that a baseless merge will be performed (obviously, because branches B and C are siblings and not parent-child). The warning was like this one:
We proceeded with merging. Then at some point it came to one developer that we forgot to update our branch B from branch A and that we need changes from changeset 1 in our branch B. But the problem is that changeset 1 has some code lines which were later modified in changeset 3 (branch C) which we merged.
Now the question is, what will happen to branch B when we merge changeset 1 from A into B after we have done the baseless merge of changeset 3 from C into B?
Will TFS be smart enough to keep the changes from the newest changeset 3 when it finds the conflicting code lines of changeset 1, even after we did the baseless merge?
P.S. We'll learn from this mistake and will try to avoid baseless merging in the future...
From your diagram, it looks like that 1 is already included in Branch C. So when you merge from "C" to "B", the changes would already include those of changeset 1.
I have two files, A.cs and B.cs, next to each other in the same branch. I want to copy/paste B.cs into A.cs such that A.cs contains its original contents as well as the contents of B.cs.
In TFS, this means a delete operation on B.cs, and an edit operation on A.cs. However, we lose the revision history of B.cs. Is there a way to tell TFS that B.cs is now A.cs?
Is this a use case for a baseless merge?
tf merge /baseless B.cs A.cs
Yes, in this case you can pend a baseless merge with B.cs as the target and A.cs as the source, then pend a delete on B.cs.
In this case, you will then have the history for B.cs accessible when viewing the history for A.cs:
We have a changeset where the developer has checked in changes to both source and target branch, many changes including renames in both branches. The merge of the the changeset from source to target branch goes fine, but the changeset remains in the list of changesets to be merged.
When I now try to merge the changeset again, it says "There are noe changes to merge.". And the changeset remains in the queue.
We have tried to use the command line tool to discard the changeset like this:
C:\src\project\sourceBranch>tf merge /discard /recursive /version:C8137~C8137 $/Project/sourceBranch $/
Project/targetBranch
This did not help. We have also tried using other options like /force and /baseless with no luck.
What other possibilities are there of getting rid of the changeset among the merge candidates?
Ok, so basically you have a changeset with items that belong to two branches that are directly related. Which makes the merge of such changeset using the "partial changeset" subcomponent of the changeset.
Let me explain with a better way:
CS1234 (your changeset)
Partial CS1234A for branch A (say the source branch)
Partial CS1234B for branch B (say the target)
You did a merge from A to B, which merged CS1234A to B.
Now when you attempt a new merge still from A to B, you still have CS1234 as a candidate, right ? Then if you select it, nothing is done, which is totally understandable due to the fact you already merged CS1234A and CS1234B does not belong to the source branch (A).
Looks like a bug from TFS to me that I already ran into, I thought Microsoft fixed it with the TFS 2010 RTM, apparently not.
Basically TFS gives you CS1234 as a candidate because only a partial part of it was merged, but as the other partial part can't be merge, it doesn't make sense to give it as a candidate.
What about:
You initiate a merge from B to A (in the reverse way), does CS1234 is given as a candidate ? My assumption is if you merge CS1234 from B to A then you won't be bother again with this changeset when you'll display the candidates from A to B. But I don't know if it's something you're willing to do.
Anyway you should fill a bug at the Microsoft Connect site
so this is what I have
valid changeset id 8
valid changeset id 7
valid changeset id 6
valid changeset id 5
invalid merge from branch X changeset id 4
valid changeset id 3
valid changeset id 2
valid changeset id 1
is there a way to "delete" or "skip" or "ignore" the invalid changeset?
if not then I will lose a week to recover from this mess.
To answer the question "Is there a way to skip or otherwise ignore a changeset?" The answer is no.
Which leaves you with three choices:
The first is to pull all the changes you want from 5 through 8 and rollback to 3. Basically, get the files that changed and hand merge them into rev 3.
The second is to look at everything that the merge updated and hand rollback those items. In short, depending on the number of files involved you are in for a long editing session.
The third option is only available to you if sets 5 through 8 did not modify the same files as 4. If this is true then just select the files from the 4th set and roll those back individually. Then check in the new set as #9. Somehow I doubt this is available to you.
If you use TFS 2010 then you can use the tf rollback command, this will attempt to remove the offending chagngeset. If there are conflicts because subsequentchangesets have modified the same code then the merge tool will appear and you can select the code you need to keep / remove.
For earlier versions of TFS you can install the TFS power tools and use the tfpt rollback command to do the same thing