There are some odd lines in the latest version of config.json and I need to analyze the content before merge, to see what went wrong with latest merge.
Assume I have $/A and $/B branches with common ancestor in changeset 1. When merging changed branches at later changeset, the common ancestor is still from changeset1.
Is there a simple tf command that will export config.json versions that created merged end result, meaning: config.json from both branches + common ancestor config.json file?
Actually I need this for specific changeset not only for latest. Sometimes I need to analyze past merge why it merged lines together as it did.
TFS 11.
I previously wasn't aware of this extension, but it looks like it'll be very helpful in your quest:
Visual Studio Marketplace - Bourgeon
You'll need to dig into the client object model to access the details to understand this, I'm guessing all the data is there...
ChangesetMerge Class
ItemMerge Class
It contains which changeset numbers were merged and which items in that changeset were merged. From there you can find the source and target items of the merge.
But you'll need to traverse the history graph to find the common base to see where these two histories diverged originally and whether it got merges since (which would update the common parent).
VersionControlServer.QueryHistory Method (ItemSpec)
You can replay a merge by creating a workspace with the source version and try merging the changeset (range) into the workspace.
(GetStatus status = workspace2.Merge(source, this.m_arguments.FreeArguments[1], versionRange[0], versionRange[1], this.ParseLockOption(), mergeOptions);
There is no command line tool for it and Visual Studio isn't really capable of visualizing the history of a single file.
tf vc merges A A-branched
Will show which changeset ranges got merges into a new changeset. This can be used to recompose the branch/merge graph.
Related
Here is a slightly different take on this question (Find the tfs path of merged branch), different enough to deserve its own question.
In the above link, the authors describe how you can programmatically traverse the folder hierarchy using TFS API to determine the parent branch object from a folder or item within a branch, and then you can get the branch information for that branch.
However, a different question is: how do you use TFS API obtain a path to a different branch of the original folder or item, taking into account that the item may have been renamed or moved in the other branch?
For instance: if I have an object $/MyProject/Main/Foo/bar.txt, I can easily figure out that the parent branch is $/MyProject/Main using the method described. However, let's I also have the following versions of this file out there that were created by branching the original files:
$/MyProject/Dev/Foo/bar.txt
$/MyProject/Experiment/Foo/bar.renamed
$/MyOtherProject/Main/openbar.woohoo
How can I determine the list of references to the specific files or folders in a branch? Clearly there is a way to do this because Visual Studio's merge dialog automatically populates the list of available targets with all references to the source file or folder, even if the source is not a branch.
If TFS has been used to move files or rename them, as opposed to using the file system and then checking in 'new' files to TFS then you can use the history window to review the full history of a file, this will show you it's branch history and also any moves / renames that have occurred, this is because tfs uses an identifier for the file rather than its name.
Scenario: Dev team has lets say 10 Work items. They resolve 8 work items and that needed changes to 50 files (checked out and checked in and during check in are associated to Work Items). They also worked on remaining 2 work items and fixed and checked in 5 files, but the work items are not completely done, so not resolved yet. Now I want to create a build with the 50 files only which are associated to the 8 Resolved Work items (and exclude from build the 5 files for the 2 unresolved bugs) . Is there a way to do that in TFS 2010?
TFS builds from changesets, so you need to find out the changesets associated with the work items you need to include/exclude. Simply browsing the history may suffice, but you may have to inspect what changesets are associated with the work items.
if you're lucky those changesets that you don't want to have included in the build are later in History, it's simply a matter of setting up a workspace containing only the history up until the changeset you need. If you're using Team Build, the default build process has parameter GetVersion that you can set to the changeset you want to build when queuing. If it's manual, you'll have to do a
tf get /version:C<changeset number>
(UPDATED) If on the other hand the order of checkins have been mixed (some of the changes that you need to exclude have been done prior to some that you need to include), the best way would be to create a branch, and then only merge the changesets you need to include to that branch. Then you can simply build from the latest version on that branch.
1)Using History, find the latest changeset with code you need (the closest prior to one you need to exclude)
2) Create a branch based on that version.
3) Do a selective merge of the other changesets you will need included in your build, skipping those you don't want.
4) Build from the Latest version on that branch.
Is it possible to view history and compare with shelvesets? We are investigating the possibility of using shelvesets instead of check-ins. From our initial investigation it seems we cannot view history like we do for check-ins.
We are using Visual Studio 2010/TFS 2010.
From http://msdn.microsoft.com/en-us/library/ms181403(v=vs.90).aspx
Section: The Difference Between Changesets and Shelvesets:
Unlike a changeset, a shelveset is a non-versioned entity. If you or another user unshelve the items of which a shelveset consists, edit several files, and reshelve the shelveset, Team Foundation does not create a new version of the items for future comparison and maintains no record of who revised the items, when, or in what manner. The original shelveset is completely replaced.
So, no, you can't review history. I am unsure on methods of comparing shelvesets. You should also read that entire section (The Difference Between Changesets and Shelvesets) as each item in it is a strong argument to not use shelvesets in the place of changesets.
I also cannot think of any reason why using shelvesets instead of changesets would be desirable, maybe you can list the reasons why you all were exploring this path. Just think about not being able to track changes, that alone should be a deal breaker (of course, shelvesets not even being versioned should just about do it)..
Like it says on the link posted by dugas, shelvesets are built more for...well, shelving things. For example, on the project I am working on right now, I did a shelveset for some refactoring changes I was in the middle of because something unrelated broke and I needed the code back to the original non error-filled version. I also use it for when I'm in the middle of attempting something and want to have a backup but I don't want to check in code just yet.
There's no versioning on shelvesets, but it is possible to compare code in a workspace, to the code in a shelveset, without pulling the shelveset files.
Pull the versions of files you want to compare the shelveset contents to, into a workspace
open the solution in that workspace
File >> Source Control >> Unshelve Pending Changes...
find the desired shelveset and bring up its details
On each file in the Shelveset Details window, you can right-click and select Compare >> With Workspace Version...
TFS will pull the shelveset file to a temporary location, show the diff, and then (?) clean up the temp file after you're done.
You'll be comparing the shelveset file contents, to the contents of the files on the local disk in this workspace. If changes were made to both files, the compare won't be able to tell and will indicate all those changes. However, you can compare the selveset version to its original (Compare >> With Unmodified Version..), to see all the changes that were made just to the shelveset file. You can also find out the changeset that was the base for the shelveset file (Properties..), and see what changes were added to the workspace version since that common base changeset.
There's no tree compare though, and this may require the TFS power tools to work.
P.S> I don't recomment trying to use shelvesets in place of checkins like this. If there's one thing I've learned over the years, it's not to fight Microsoft's designed-in workflows -- you do things their way, or you find a different tool. Microsoft doesn't intend you to use shelvesets this way (they want you to use changesets and a branch), and if you try, you'll constantly be fighting Microsoft's designed-in workflow.
You can use shelvesets for peer code-review before committing them to the repository ... and also for parking commits before going through a gated build process.
They are not suitable for anything other than "quick shelving" of work - use branching if you want to have multiple parallel work streams.
I am trying to understand the history of my codebase, which resides in TFS 2005, and I encountered a changeset where all changes were marked as both branch and merge.
Name Change Folder
------------------------------------------------
A.cs merge, branch $/Root/Solution/Project
I am unable to find anything (especially on MSDN) describing what the various combinations of Add, Edit, Delete, Branch, Merge, Undelete, Encoding, etc mean. Each is pretty self explanatory when used alone and some do not make sense together like Add and Delete so I am looking for information on the legal combinations and what they mean.
Merge can be combined with anything except Add. On its own, Merge just means that (1) whatever happened is the result of invoking the Merge command (2) when you checkin, TFS will record the appropriate merge history metadata in addition to the changes themselves. The remaining operation(s) in the list of changetypes tells you exactly what kind of change is being applied to the target item. Thus:
Merge, Branch = an item that exists in the source branch but not the target branch is being copied over to the target for the first time
This might make sense if the file were created during a branch operation and changes from the source branch were then merged into the new branch without having checked in at any point.
Our project has hit a point where we need to split off some code into a separate team foundation project. We would like to move these files so they retain their version control history. Temporarily we are copying the files back to the original team foundation project and re-adding them just so that our daily build & test process doesn't break. As we are able to modify our build & test process we will start to remove these temporary copies.
One issue we are noticing is that we have a nightly script that checks various maintenance branches to see if there are changesets that haven't been merged back to trunk. It is now whining about changesets that have been merged before. These changesets seem to be related to the files that have been moved and re-added. Any ideas as to why we are seeing this and how we can discard these merge candidates? If we do a merge /discard TF tells us "there are no changes to merge". It seems to be confused. Also are there other problems we might run into with this approach? Perhaps there is a better approach?
The solution that I found was to merge /discard all other changesets, then do a "catchup" merge /discard i.e. not specifying any version info. This generated a number of merge related pending changes but when I went to check them in, I got a TF14088 error. The workaround for this error was to checkin just the problematic files/folders first and then check in everything else.