A google search and a specific stockoverflow search hasn't found me anyone else with this problem.
In tfs our procedures are that we make changes in a branch called Dev, than at a later time merge specific changesets up to a branch called DevQA. (We have other branches as well which shouldn't be affecting things at this point.) We use screens available in VS to do this.
I have 9 changesets which I made last week (all relating to the same or at least overlapping code) and it's now time to merge some of those up to DevQA.
The changes are showing in History on Dev, but when I choose merge, then specific change set (set the source to Dev and the target to DevQA) and click next the list of change sets available to merge does not include 7 of my 9 changes sets, including the ones I want to merge.
I've done some checks and they appear to be the only missing changesets, others have either been merged already, or are available in the list.
I have clicked on one of the changesets and used the 'track changeset' & Visualise options, and it shows the change set has NOT already been merged.
A new branch was created after these changesets were made, which was branched from DEV and my changesets show as being in that. However I don't believe this is related because other changesets which are in that ARE available to merge to DevQA.
Is there any reason these may not be showing up? Is there any way I can work around this and force them to merge?
If the changesets are in sequence or you don't mind to merge other changesets which in the range of your nine changesets, as a workaround you could try to use tf command.
Using the tf command line tool you specify a range of versions by separating the version with a tilde character.
tf merge /recursive /version:C1000~C1008 "$/SourceBranch" "$/TargetBranch"
In this case the changes 1000 and 1008 will also be included.
To merge multiple separate changesets into another branch you will have to do it in multiple steps:
tf merge /recursive /version:C1001~C1001 "$/SourceBranch" "$/TargetBranch"
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.
Related
My Main branch seems to have change sets that my Dev branch does not have, but they are older. How should/can I clean up the changes sets?
The following is trying to merge Main into Dev and says there are changes. My understanding is that if Main and Dev match I should not see change sets during this merge anymore.
If I merge from Dev to Main I see no change sets.
Should I merge these even though newer change sets have already been applied? Example changes were made and merge into Main on 4/25.
Will this overwrite current code or will it really just update histories?
You could use tf merge command with /discard option.
/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.
Sample command：
tf merge $/Project/SourceBranch $/Project/TargetBranch /discard /recursive /version:C56693~C56693
It discards changeset 56693. The version is a from ~ to, so you can discard multiple changesets at once. When the command has finished, you still need to check in the merge.
I understand that when performing a merge from BRANCHA > BRANCHB and selecting “Keep Target” on some files will result in “Merge Credits” being granted to those files in TFS history: Merging Developement Branch to Main: There were no changes to merge
Is there a way for us to revoke/wipe the Merge Credits on given files, effectively enabling our developers to perform a /force merge via Source Control Explorer?
Context:
On a weekly basis, we merge from BRANCHA > BRANCHB to synchronize parallel efforts. Any files with unresolved conflicts are noted and their owners are notified to perform a merge on those files from A > B. We then select “Keep Target” on these files – anticipating a future merge by the file owner to resolve the pending conflict. We’re delegating the work out to the individual owners.
This doesn’t quite work though, because TFS will see that the initial merge has “resolved” the conflict (basing its evaluation on prior merge history, not file contents).
I want to enable developers to perform re-merges on these files without forcing them to use the command prompt and /force switch.
Moving forward, my plan is to “Undo Changes” on those pending changes that were selected as “Keep Target” before checking in a branch>branch merge. This will enable the devs to perform the merges independently by dodging the merge credits.
But looking back, a branch<>branch /force merge results in hundreds of conflicts that we would like to delegate out to the owners as a means of syncing up two branches. Performing a classic merge reports nothing on these because prior merges have “Kept Target”.
You're indeed better off undoing the merge for the specific files you don't want to merge right now, but once you've chosen keep target, TFS indeed remembers that choice.
If you're already past the point of committing the merge, there is a way to get rid of the ticket, and that is to roll back the merge. You can roll back the merge for a group of individual files.
The trick here is as follows:
Look up each file and them in the Source Control Explorer.
Right-click the individual file and from the context menu choose to Rollback....
Enter the changeset number of the merge
Repeat 1 to 3 until you have all the file in your list.
Check-in this compensating changeset.
Try merging Branch A to Branch B again, your candidate changes should show up again.
You can do the same thing from the commandline, using tf rollback (pre-2015) or tf vc rollback (post-20215)
Newb question, I want to make sure I understand this.
When I git checkout <revision>, does this return the entire project to its state at that moment, or does it only recreate the files changed in that particular revision?
For example: If my folder was completely empty besides the .git repo, and I git checkout master, will the resulting files be the project in its entirety, or only the files changed in the most recent commit?
I ask, because I am checking out my project at various points (starting from the beginning), and instead of the project slowly growing in size as one would expect, the size of each checkout is varying quite a lot.
When I git checkout <revision>, does this return the entire project to its state at that moment, or does it only recreate the files changed in that particular revision?
If your working tree and staging area are completely empty (besides the .git subdirectory, of course) and you run
git checkout <revision>
then your working tree and staging area will perfectly reflect the contents of that particular revision.
On the other hand, if your working tree is not empty when you run git checkout, what happens is much more subtle, and may be broken down into three cases:
The checkout is not problematic and Git carries it out without batting an eyelid: the contents of that particular revision get copied to your working tree (and overwrite stuff already present there, if needed). Or
The checkout, if it were carried out, would result in a loss of local changes; therefore, Git (under the assumption that you didn't use the -f flag) tells you off and aborts the checkout. Or
A more complicated situation may arise in which stuff is only partially checked out, and some local, uncommitted changes are kept in your working tree and/or index. More details about that situation can be found in my answer to Why are unstaged changes still present after checking out a different branch?.
[...] the size of each checkout is varying quite a lot.
Are you taking into account untracked files? Did you commit, then later remove large files? On the basis of the information given in your question alone, we can do little more than hypothesize about the reason why the size varies a lot.
From the documentation: "Updates files in the working tree to match the version in the index or the specified tree. " In the case of your example, it will return the repository to the state at the time of the checkout in its entirety.
However as Jubobs pointed out there is a difference in behaviour if you have made any changes to the state of your repository since your last checkout. His answer is more comprehensive than mine if this is the case.
Also note that this will only apply to files that are tracked by git, so any other files you have lying around will not be affected.
So rolled back my merge successfully in vs 2008 using the tfs powertools tfpt command.
I tried to re-merge and it said there were no changes (but there are).
Which brings another thought to mind. When I checked in my merge it had about 20 files in the check in even though I only changed 2 files. Now, when I did the rollback it only gave me back the 2 files that I changed to check in?
Thats the normal TFS behavior. This is how TFS rollback works, TFS rollback is not actually a "rollback" per say, it's a new changeset overwriting the latest version with an old version!
You have branches A (parent) and B (child). You made some changes to B and then did a merge to A. TFS now assumes that all changes from B is present in A and updates it's internal DB with timestamps. When you rolled back the changes in A (parent) it doesnt change the updates made by TFS to its internal DB. TFS just considers that as a new change! So for TFS there are no changes between B and A, because nothing has changed in B since the last merge! Makes sense?
"When I checked in my merge it had about 20 files in the check in even though I only changed 2 files. Now, when I did the rollback it only gave me back the 2 files that I changed to check in?"
When you say merge shows 20 files -> if you open the merge changeset you can actually see which all files got edit and which all just got merged. Against each file in the change set there will be an entry saying "merge, edit"/ "merge"/"branch"/"delete" etc. Those tell you what exactly happened with that merge for the particular file.
In your case I am assuming you have "merge" next to those 18 files. Rename is the most common reason that I have seen for this. There are a number of possible reasons. This is not a complete list:
You performed a namespace operation (delete, undelete, rename) on a parent folder of the files marked "merge"
You performed a namespace operation (delete, undelete, rename) that had already been performed in the target branch
You performed a sequence of namespace operations that collapsed into a no-op (eg delete + undelete, or rename a -> b -> a)
There are unresolved conflicts
You performing a discard
When I perform tf rename $/Project/Main/File1.cs $/Project/Main/File2.cs in TFS2010, I know that once I check in there will be a "rename" change on the $/Project/Main/File2.cs slot, and a "delete, source rename" change on the $/Project/Main/File1.cs slot.
However, while the changes are still pending, only the rename change exists as a pending change. No changes are displayed in Pending Change to indicate that $/Project/Main/File1.cs is being renamed. In fact, if you execute tf status $/Project/Main/File1.cs tf.exe claims there are no pending changes, which is totally false.
In my situation, I have a series of about 100 files that I have manually merged as part of a branch integration operation, and following a re-execution of the tf merge command at the command line, I am simply trying to undo the files to which they apply so that I may unshelve the merged changes.
However, the Tfs object model's PendingChange objects can supply me only with the ServerPath, which refers to the "source rename" item, not the "rename" item. I am at a loss about how I can trace my shelved pending changes to the items that would need to be undone in my workspace.
How can I get the original pre-rename server path for items in a shelf that have been renamed?
You could get specific version to a point in time that the files mapped correctly and take note of the paths there.
Also, you could try TF Rollback. If you supply the changeset where you manually merged those 100 files you will, at the very least, get a list of all relevant files if you rollback (you dont have to checkin the rollback but rather just use it to visualize the files). From there, you should be able to figure out the related files.