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
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.
I have a question about merging between branches in TFS 2013, specifically about merge discard, that I haven't been able to find an answer for in other threads.
Scenario: we have two branches, let's call them $North and $South - to emphasize they are not to be looked upon as source and target (i.e. merging can be done in both directions). $South was branched out from $North.
I check in changeset nr. 1000 to $North, and the changeset appears expectedly as a merge candidate:
> tf merge /candidate $North $South /recursive
Changeset User Date Comment
1000 Bob ... Updating build script
Then I do a merge discard because this changeset is not relevant to merge to the other branch, in fact it is not application code but rather configuration specific to the branch:
> tf merge /discard /version:C1000~C1000 $North $South /recursive
Resolved file1 as KeepYours
...
I check in the merge discard resulting in changeset nr. 1001. Now changeset 1000 has disappeared from the merge candidate list:
> tf merge /candidate $North $South /recursive
There are no changes to merge.
BUT, now I check the merge candidates in the reverse direction:
> tf merge /candidate $South $North /recursive
Changeset User Date Comment
1001* Bob ... Merge discard on changeset 1000
I even tried to rollback the merge discard again, because I would rather have the change as merge candidate from $North to $South than in the other direction, but the result was just another merge candidate:
> tf merge /candidate $South $North /recursive
Changeset User Date Comment
1002* Bob ... Rollback on merge discard on changeset 1000
1001* Bob ... Merge discard on changeset 1000
Does anyone know if it is possible at all to completely discard a changeset, and also not having the discard itself appear as merge candidate in the other direction?
(Although I don't know if the contents of my initial changeset is relevant, I can add that my actual changeset 1000 was a change in $North that consisted of a delete on a folder that was also present in $South, and also a folder add.)
Weird scenario, when I tried on a single file yesterday, I couldn't reproduce your issue. When I try a new test today by adding a new folder, I couldn't reproduce your issue at the first attempt, but when I attempt a new merge, I could reproduce your issue. Obviously, we are not the only persons have this issue, check TFS Merge: Cannot discard a changeset, you may submit a feedback at http://connect.microsoft.com/VisualStudio for this random issue.
By the way, sometimes, combining /baseless /discard would force a file to be considered for the merge and then discarded by the discard switch.
According to the description for "/discard" on MSDN:
/discard
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.
The history of the branch is still updated even though the merge isn't happened. You can check the history of your branch, there should be a changeset 1001 in it.
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:
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.