Using the TFS API I am trying to approximate bugs/file.
A bug (as I define it) originates from a file in a change set that has been associated with a work item that has type WorkItemType = 'Bug'. For example, in branch-a, branch-a/1.txt and branch-a/2.txt are checked in and associated with a 'Bug' work item. Call this changeset X. There are now two bugs in branch-a associated with those two files.
If I merge branch-a back into its parent (the root branch), the root also gains these bugs, so root/1.txt and root/2.txt are also bugs - basically the root branch has gained the buggy history of it child. Bugs can be inherited in this fashion. This property is preserved across renames. So if root/1.txt was renamed to root/hello.txt it's still a bug.
I start with iterating over all "Bug" work items in the TFS project:
In this example there is a single work item, which is associated with changeset X, which is associated with changes on branch-a/1.txt and branch-a/2.txt (although those files could be renamed now in the present).
Now I want to know all places where branch-a/1.txt and branch-a/2.txt ended up (once again, even with renames).
So, given a Changeset cs and a Change c within cs, I want know for each branch if c made it into that branch and the most recent file name where c resides.
Another way to think about the problem is thinking about moving forward through history. I start at specific point in time with a change in a single branch. Now this change needs to be tracked all the way to the present.
Any ideas? I can provide clarification as needed.
Thank you!
Have you tried tracking the changeset?
View History on the file that has the change (1.txt) > Right Click on the changeset > Track Changeset > Check all visible > Visualize.
Not sure if this is exactly what you want but it might a good place to start.
Video that shows it: YouTube video
Not sure if it's possible using the API. This link seems to suggest that it's not possible using API calls. This link seems to suggest that it is possible.
Related
We've had this happen more than a few times were we consider it to be more than a fluke at this point. When we are merging back after we are complete with our branch there are way more changes then their should be. So most of the files showing as pending changes never changed (in most of the cases in neither the branch or the base). When i compare them (i use beyond compare) there are no differences. I haven't went through all the files that didn't change but in most cases it seems like they are marked as [merge] and the files that actually changed are marked as [merge,edit].
In one case we probably changed around a 100 files it pending changes showed more than 22,000 changes. We tried checking them in at one point thinking tfs would be smart enough to know what files changed and which didn't. But it checked in all files. Does anyone know whats going on and how to fix it?
We are running TFS 2012 w\ Update1
Everyone is using Visual Studio 2012 w\ Update 1.
For anyone having the same issue a work around is to undo your pending changes. When you get the confirmation dialog choose "No to all". Only your pending changes should be left.
Regarding the problem where you had changed 100 files and TFS wanted to merge several thousand. This is usually caused by renaming (or deleting and then un-deleting, or moving) a branch. This has bitten me a couple of times and I feel your pain.
The best advise I can give is, once you've created a branch, leave it alone. Don't move it, don't rename it. If the location or name of the branch are wrong, live with it until it's time to delete the branch and create a new one.
Because of the way TFS 201x work behind the scenes, changing the root folder of a branch effectively turns it in to a different object. When you try to merge the branch again, TFS will perform a baseless merge which effectively means that it appears that all files in the branch have changed (even though they haven't) This is new behaviour, older versions of TFS (2005 / 2008) don't suffer from this problem.
e.g. you have a Team Project that looks like this
$/TeamProject/Main
You then create a branch from "Main" called "Dev"
$/TeamProject/Dev
You can merge as much as you like and there shouldn't be any problems. Then you decide that the folder structure might get a bit messy when you have several dev branches so you create a folder called "Development" at the root of the team project and move the dev branch in to this folder
$/TeamProject/Development/Dev
OK now behind the scenes the move is a rename and a delete, the old dev branch still exists under $/TeamProject/Dev (you can see this by going to "tools", "options", "Source Control", "Team Foundation Server" and then check the setting that says "show deleted items in Source Control"
The folder called $/TeamProject/Development/Dev is actually a brand new thing! Therefore it doesn't have a merge relationship with "Main". Confusingly though the IDE will show a relationship, but really it doesn't exist. The first time you merge from $/TeamProject/Development/Devto $/TeamProject/Main TFS will perform a sneaky baseless merge to establish the branching relationship.
The same thing happens if you rename a branch (the old branch will be deleted and a new branch will be created under the covers)
This Blog goes in to some more detail
The comment above with the "No to all" option in the undo confirmation dialog works okay, but as commented by Mark Hosang, this will not work right if you have new files. Mladen Mihajlovic is right that you can make sure to not select those new files. However with a large code base, wading through this is very tedious.
So my method: before getting to the confirmation dialog, you are presented with a window to select which files to undo. This window has sortable columns. You can sort by the Change column and select only the files with merge status (these are the unchanged files; merge, edit are edited files and merge, branch are new files). Just click Undo Changes with just those selected, and then enjoy the beauty of an uncluttered merge changeset.
Try this:
select all pending files
on context menu click 'Undo...'
in the 'Undo Pending Changes' dialog sort files by 'Change' column
deselect all files except 'merge' using shift+click
click button 'Undo Changes'
From my experience this happens when TFS has no relationship between file A in branch A and file B in branch B.
When merging branches TFS always creates a relationship between the files when no relationship is present already. Hence it wants to check in as "merge" to remember these relationships.
I tend to undo these "merge" changes when i don't need the relationships (e.g. for reparenting).
In order to clean up my project structure, I moved a folder into another (new) folder through the TFS Power Tools Shell-Extension (Rename/Move).
After checking the history at the new place, the move is the only entry. (I tried one folder up, down, even on single files in the moved folder.. same result.)
I had also put on some labels on versions of the folder before the move, since there were some important states of the code I wanted to get back to.
So.. what went wrong, and how can I either get the history or at least find out the label names again and check out those versions?
Turns out it is pretty easy.
In Visual Studio 2010, go to Tools->Options. There you can find the option to show "deleted" items (roughly in the middle of the dialog box). The old folder got deleted during the move - it will be displayed again after activating that option. (They will be kind of grayed with a red cross.)
Labels seem to have disappeared, though, so I had to go by version.
In the Source Explorer you have the normal operations again - like View History or Get.
DISCLAIMER: For reference of everyone that gets here, this answer is not fixing #Andreas problem, just giving some context on why this happens and offering a couple of workarounds.
Seems that losing history when moving folders in TFS 2010 is not a bug, is a "feature". (still happening in TFS2012. From this MSDN link you can read official Microsoft answer:
Thanks for the feedback here. The previous comment about this being by design is correct, and there is an option on the command line. In the UI, history of folders is recursive - always. This is because most of the time, users care about the history of the contents of the folder. Files on the other hand dont have the concept of recursive history - you always see the history for the file itself. Now, from the command line, there is an option to show recursive history (/r) and if you run tf history on a folder without the recursive option, you'll see the changes to the folder itself. This would include changes such as a rename for the folder itself.
Workaround to get history once lost: As you can see there, you have a workaround using tf history.
Workaround to avoid losing history: If you want to avoid losing history in folders instead of using move feature, you can use TFS Integration tool to migrate code from one folder to other preserving history, migrating from $/TFSCode/FolderA to $/TFSCode/FolderB. It is a little bit overkill but if the history is pretty important for you is much better than looking for it in deleted folders
It is true that the folder history is lost, but the individual file history is actually not lost. It is hidden under the little "expand me" arrow at the far left on a file history line. Expand it on the oldest history entry for a file, or anywhere you see it, and you will see history of that individual file also from an old location that no longer exists.
At the top of History window you can edit Source location, put the old name and get the full history before it has been moved.
Also, is good to mention that you can get the full history back by moving/rename the branch back to the old location/name.
A blog states
Labels come with a big warning though - labels themselves are not
version controlled, meaning that there is no way to track or audit the
history of activity on a label. Plus, labels don't keep copies of
versions in case of a file deletion, so if a file gets deleted, any
label that relies on a version of that file is essentially hosed.
This is not the only place I've read similar information regarding TFS labels. The lack of history is clear enough. The second part "labels don't keep copies of versions..." is unclear. In fact, I created a test project > labeled it > deleted a file > performed a Get by Label and the file came back. So what is this referring to? Has the label functionality changed in TFS as of recent?
I realize that a file deletion does not actually remove history, is that the cause? In other words, if I run
tf destroy "$/MyTeamProject/Project/FileName.cs"
Is that what it means to delete a file? If so, that seems an extraordinary circumstance to even consider. I mean, its an intentional unrecoverable deletion of history. Changesets are not going to be any improvement over labels in such a case.
When we apply a label we do so to a version of source control at a point in time. Intuitively, because we initially created a snapshot of source control at a point in time one may assume the snapshot represents source code at a point in time.
This is incorrect. Labels can be edited after creation.
Conceptually, a label defines a product and the product’s bug-fixes (source). A real world example may help. Let’s say we have a product called AlphaBoogerBear. AlphaBoogerBear is a product, not a version (think pre-release Windows names). AlphaBoogerBear can be made into a Label, AlphaBoogerBearLabel. We perform a release of AlphaBoogerBear. There are some bugs. We fix them.
Now, we go back and edit AlphaBoogerBearLabel to include the bugfixes. The label no longer represents a snapshot at a point in time. Instead, it represents the most stable release of AlphaBoogerBear.
Finally, we move to BetaBoogerBear. We have the option to go back and grab a label that represents the old product at its best version in time.
In my opinion, if one requires a snapshot of version of source control it's better to branch. If one requires an edit-able snapshot that represents a product release then a Label is useful. Albeit, it seems a difficult balance of trust and convenience.
As far as the author's intentions, I really can't say for sure. He could mean to say that items can be deleted from a label and thus when you Get by Label the item will be gone. Though, the item is still stored in TFS history so although it is a confusing situation, not all is lost.
I'm not sure what is meant by the sentence about labels getting affected by file deletions. But you have it right, a regular file delete won't affect labels, but a destroy will.
What it's cautioning you about with respect to not being version controlled though, is that somebody can come and edit a label, by including or excluding files from the label, or changing the versions of files included in the label. And there will be no history of these changes to the label definition.
As I understand it, a label in TFS is basically a set/collection of changesets.
Let's say you label a directory with two files in it. The label would then consist of three changesets: one for the directory and one for each file. Deleting one of these files in TFS will produce a new changeset for the directory, so doing a Get by Label at this stage would get the deleted file "back" since it contains the changeset prior to the deletion. Destroying a file would remove it from any changeset records it has appeared in, thus also destroying the information in the label.
Since the label is identified by its name only, it is also very easy to overwrite it with a new label, destroying the old information. The /child parameter to this command can change this behavior somewhat: using /child:merge will keep the changesets that were previously recorded along with the new one, /child:replace will exchange the old changeset with the new. In the example above, none of these alternatives would make any difference, since Get by Label would still retrieve the highest changeset.
I am still on the lookout for a Eclipse-like ROR IDE (at least it should have the functions that I am more or less used to having), and have decided to conduct a trial of RubyMine.
Unfortunately I quickly discovered two things:
Git log/history view: There isn't an equivalent for Link with Editor and Selection (it's the function that allows the history to be updated and limited to changes applicable to the active document at any point in time)
The closest is a per document history on separate tabs, there is no linking with editor or selection.
There is no way to reset to a particular commit (or branch from it) by right clicking on it. Is it really worse than gitk in this regard?!
Reset/branch at a particular commit is not possible at the Changes or the Version Control view (though possible via Checkout/Reset Head with ability to specify commit hashes). The context integration has room for improvement in this regard.
I would be very glad to be proven wrong on either/both counts.
Edit: Updated with input from CrazyCoder
There is no exactly this feature, but there is Show History from the file context menu. Multiple history tabs can be switched between in the Version Control panel.
Changes | Log panel has these actions in the context menu (New Branch, Checkout Revision).
When I merge files from one branch to another and then go to check in files into the target branch, there are MANY files checked out, just the ones that changed. For example, Main and Critical branches were the same and we made changes to only 2 or 3 files on the Critical Fix branch. I then merged Critical ==> Main, and when I went to check in changes to the Main branch I noticed that there were numerous files checked out, not just the 2 or 3 that were actually changed in the Critical Fix branch. Moreover, when I compare a file from the Main branch to one on the server, I am told that the files are identical. If the files are identical, why are they checked out? Any help would be appreciated, or even a link that explains how TFS 2010 does merges.
The default Source Control Merging tools in Visual Source Safe and then TFS have always been rather poor - they are often confused by the simplest changes, often detect identical files as being "changed", and the auto-merge facility frequenty fails (includes the wrong changes). I quickly learned distrust for these merge tools (in about 1995) and have not seen any evidence in any of the new releases since then that the core merge algorithms have been improved at all.
The good news is that you can replace the client-side merging tools with third party ones (I use one that works so well that I actually trust its auto-merge option. I once spent 2 days trying (and failing) to do a complex merge with the TFS tools and in the end bought this 3rd party tool and re-did the entire merge successfully in 15 minutes!)
The bad news is that the first step of branch merging just uses the TFS merge code, and so it gets confused a lot, resulting in the symptoms you've described. This is frustrating in such a key feature of such an expensive application as it wastes a lot of programmer time on every merge to fix imaginary "conflicts" - on the plus side, with the help of 3rd party tools it is usually very easy to reliably resolve these merge issues.
I have had the same problem. I created a branch of our DEV branch and made changes to a few files. I checked in my changes and merged the latest changes to DEV into my branch. After the merge all 30,000+ files in my branch were marked as changed. Just like cju, I found that a comparison of most of the files showed that no changes had been made.
I decided to undo all changes and try again. When I right-clicked on the solution and selected Undo, I got a message that one file had changes, was I sure I wanted to undo that file? I clicked "No to All" and when the undo operation was complete, only the files that had been changed during my merge from DEV were still checked out. This was exactly what I wanted so I checked those changes into my branch and continued working.
I hope others can correct their situation as easily as I was able to.
One thing I noticed is that when one file is changed in different branches resulting in exactly the same content, then merging marks it as a conflict since the file is changed in both places. Of course a difference view of the file notices that there are no changes and therefore an auto merge solves this automatically for you.