Context: TFS 2010
Detail: a changeset where the comment on the changeset has changed at least once.
Question: Can I see the history of the comment on the changeset somewhere?
There is no history kept on the changeset. It's overwritten on the changeset record. It's a single string (nvarchar(max)) field in the ChangeSet record.
And if I'm reading the Warehouse schema correctly, the warehouse also keeps the ChangeSetTitle in a single dimension and the data isn't duplicated for each time the comment changes.
Related
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.
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
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.