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.
Related
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.
I've read several posts about branch and merge feature of SVC and creating branches in TFS, following those steps I've created branch for a breaking change in a feature of ASP.NET MVC application,
After successful creation of branch, branched files (new files) excluded from application, attempting to include files in project will create duplicate signature errors.
so I've to carryout changes in original files (files available before branching) now I don't know actual purpose of branches.
If I need to work with existing files why do I need to create branch?
How to setup and configure branching operation in TFS Version Control?
How really it helps?
Edit:
Attached image
I've created a branch # controller folder (Source Control Explorer), After successful creation of Branch I found two directory in One Controller another Controller-Branch (which is excluded from project by default). Now in what set of files I need to work?
When I Work in "Controllers" file set, these changes push back to other developers and so I don't see any isolation of environment there.
If I need to work in "Controllers-branch" why it is excluded from project? when I attempt to Include "Controllers-branch" to project, code definitions, class names duplicated (i.e., these definitions conflicts with contents of "Controllers" folder)
Why there have two branches Controllers and Controllers-branch:
It’s because when you created a branch (branching and merging -> branch) based on Controllers folder, you also select Immediately convert source folder to branch (enables visualizations), this will convert Controllers folder to branch.
So based on your need, you should convert Controllers branch into folder (right click Controllers branch -> branching and merging -> convert to folder).
Why Controllers-branch is isolate from your project:
It’s because Controllers-branch is a branch, and the TFVC branch can achieve these goals:
• Manage concurrent work by multiple teams on the same codebase
• Isolate risks that are introduced by different sets of changes to
the codebase
• Take snapshots and then support subsequent isolated
changes (for example, to create a release branch)
So it should be works isolated. If your work own is not only updated files in Controllers folder, but also need to modify files for the whole project, you should create a branch from ApplicationMain folder a,d make sure Immediately convert source folder to branch (enables visualizations) is not selected. Then you can work on ApplicationMain-branch concurrently from other developers.
Another developer has some test files in a new directory in their branch. They're useful to me as well but I'm working in a totally independent, newer branch and he's not likely to merge his branch anytime soon.
I am able to branch his "test-data" directory into my branch but I really want to break the branch association so they're treated as new files in my branch, i.e. so TFS thinks our branches independently added the same new files and we resolve conflicts later since our test data is likely to diverge.
Is there a way to "orphan" the branched files somehow?
You can just get files in TFS using the web access component. Just browse to the folder through the code portion of web access and right click > get as zip.
You can do it from the command line as well but I am not familiar with that. SO has a lot of resources on how to do that from what I have seen.
It is possible to break the branching relationship in TFS and there are many questions on SO on how to do that. But your branch wouldn't initially treat them as 'added' and the history will be in TFS. I would recommend branching just the folder his useful code into your branch and leaving that relationship for posterities sake.
That being said, depending on your situation it may not make sense. If you want to remove the branching relationship immediately, then I don't think you need to use TFS.
Using VS2013 and/or VisualStudio.com, is it possible after creating a branch ("Main" branched to "Dev001") to view a list of all the files that differ between "Main" and "Dev001"?
For example, I'd like to see all the files that have been amended/created within the current branch, since it was branched.
The closest I have got is right-clicking the branch, selecting View History, then clicking each changeset to view the files in the Changeset Details panel, however, there are many changesets in there which is taking a long time.
Please note I am not using Git.
Just right click on your Main branch in Source Control Explorer an select Compare.... From there you can specify the path to your branch and the versions you would like to compare.
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.