When I do Track Changeset in tfs 2010, then in branch visualisation, I only get to see that selected changeset. However in examples all over the web, I have seen multiple changesets being shown in the hierarchy and Timeline views. Any idea?
What I have got is a main branch and from that I created a dev branch. Then i perform two changsets on dev branch. Now when i do View History on dev branch and select any one of the changeset and perform Track Changeset, then it only shows me that changeset, which is a bit odd because in the timeline view i should be able to see multiple changesets in a time range. Any idea?
Nabeel
nabeelfarid,
You likely have figured this out by now but this may be of use to others. The activity you are performing is called "Track Changeset" and thus by it's default nature and its name it is tracking a single changeset. It does also seem intuitive to me that in a timeline view I could see changesets that were merge candidates versus a single tracked changeset but that is not how it functions. It is only showing the tracking of a single changeset.
There are instances where instead of seeing a single changeset in the branches the tracked changeset has been merged into that instead you will see multiple changesets show up in one or more branches and usually with an * by them. This happens when the changeset that is being tracked has some of the files in the changeset merged into a target in one merge and checkin operation and some or all of the remaining files of the changeset merged into the target under a second (or more) merge and check-in operation.
Take a quick look at this blog post from John Bowen. He has a nice example that shows a a tracked changeset merged into a parent target branch as multiple changesets made up each of a subset of the files in the tracked changeset. He also shows how that might then look if they were forward integrated from that parent into a different child also by way of multiple changesets.
Visualizing Changes Across TFS Branches
If your changesets on dev have not been merged back to your main branch then there is nothing to track. Only as a consequence of merge operation will your dev changes gain a relationship with another changeset (which in your case will be a changeset committed to the main branch).
That is the purpose of the changeset tracking, to help you visualize the propogation of your change across branches. This is useful if you need to verify whether a specific branch has received your changes made on another branch.
(One thing to be aware of is when selecting Track Changeset, in the subsequent Select Branches dialog select all the branches you want to see in the visualization. It may be the case that just the branch associated with your starting changeset is selected and again you will not see the associated changesets on other branches).
Related
One of my projects in TFS keeps displaying changesets as unmerged between the branches after I have already merged and committed them. I used the Track Changeset feature and clicked the Visualize button to see if the change was merged. It shows that it was merged but has a different background color and an asterisk. I checked the help and it gives this explanation:
If a branch has received some (but not all) of the changes in a changeset, the branch is filled with a pattern, and an asterisk follows the changeset numbers within that branch. For example, the previous illustration shows that only some of the changes in changeset 38 were merged to the Test branch
Track Changes Help
I don't understand how it is that I only partially merged those changesets. Perhaps I did not have latest when I completed the merge but it is happening to a lot of the changesets and this only happens on this one branched project folder.
Is there a way to find out what did not get merged and merge it so that the changesets will quit showing up as a merge candidate?
A partial merge is recorded when only some changes from a changeset are merged into the target. There are two common scenarios in below which you can end up with partial merges:
Scenario 1:Undo some pending changes when you are checking the merged files
In this case, even though we already merged changeset Dev to Main, it is still a merge candidate. This is caused by the fact that the merge engine detected that there are still some changes in that changeset which were not propagated from Dev to Main.
Scenario 2: Performed the merge at feature level not from the top of the branch
For example: consider that you have two branches Main and Dev, each of them has two folders (Feature1 and Feature2) and each feature folder contains one file. We edit both files from the feature folders (Dev\Feature1\feature1.txt and Dev\Feature2\feature2.txt) and check-in the changes.
If you perform the merge operation at the Feature1 level.（Changset142→
Changeset143） You will notice in the Pending Changes window that only the edit done in the Feature1 folder will be merged. Complete the merge.
If you take a look at the merge history of the Feature1 folder you will see that all changes from changeset 142 have been merged into changeset 143.
However,if you take a look at the merge history of Main you will see that only parts of changeset 142 have been merged into changeset 143. This is normal as changeset 142 has some changes – the edit of the file in the Feature2 folder – which were not delivered.
In case of a partial merge, to figure out what changes have been merged and what changes from the changeset were left out. The only way to achieve this is to diff the contents of the changeset that was partially merged, and the contents of the changeset that was generated as the result of the merge. More detail info you can refer this blog: Partial Merges in TFS – A Guide
Update
You can do a discard
merge.
This has to be done from the command line. Open up the Developer
command
prompt,
then navigate to a folder under either of your branches (i.e. navigate
to one of the affected
workspaces).
Then type:
tf merge /r /discard "$/Project/B1" "$/Project/B2" /v:C12345~C12345
This will take the changeset identified (in this case it was changeset
#12345), and update it as merged to the target branch (branch B2). The target files will be checked out, but they will not be changed - you
can simply check them in to complete the operation. After that the
changeset will no longer appear as a merge candidate. You can specify
a range of changesets to merge at the same time, but they should be
contiguous.
Note that after doing this a changeset will occasionally still show up
as a merge candidate - this is rather uncommon with the latest
versions of TFS, and it is virtually impossible to fix (unless you are
running your own local install of TFS and want to get your hands very
dirty in the database). If you end up with one of these marooned
changesets, just ignore it.
Source:
Finding merge candidates in TFS
Let's say I write some code for a ticket, and check it in for code review (changeset A). The review comes back illustrating some changes that need to be made. I make the required changes, and check it in (creating changeset B). Assuming changeset B renders changeset A obsolete, when it comes time to merge (perhaps from trunk to a deployment branch), should both changesets be merged into it, so that the history is kept, or only the final, correct changeset?
I was under the impression that a correct merge would contain all changes made to a file so that the history could be kept, and there are no dangling changesets in trunk. However, I'm getting some resistance on this in my team. Thoughts?
You should mostly be merging "latest" rather than picking and choosing changesets. If you merge latest then TFVC handles all of the details of merging multiple changesets. You can also choose to merge only up to a specific changeset rather than latest.
http://nakedalm.com/avoid-pick-n-mix-branching-anti-pattern/
As your delevlopers are choosing changesets to merge they are actively reducing the quality of the final product. You are in essence maximising the number of potential integration issues...
We currently have up to 3 developers working in the same branch.
In Jan, I submitted changesets (say 100-110) that have since had some code overwritten by changsets (111-300) during merges from other team members. I'm now just getting back to my project and I dread having to manually re-type all that code.
I can identify the exact changesets I need.
Is it possible to "merge" these specific changesets into the latest version of the same branch?
You can merge the changes in the same branch.
GO TO Branching and Merging option and click on the merging option you can merge the changes by choosing change set, date or label.
Hope you get my words
We have begun using the following branching structure in TFS 2010:
All changes so far have been performed in the Development branch, and all check-ins have been associated with a Task work item. The Tasks are all children either of a Bug or a Product Backlog Item work item. Each CI build is triggered for a particular changeset, and the changeset is associated with a Task, so we can manually figure out which Bug or PBI was just built.
Some time after the code has been built, deployed to our Integration environment and tested by the developer, it is merged to the Main branch. Obviously, more than one changeset may be merged to Main at the same time. The nightly build will build this code if we don't manually trigger the nightly before that. QA will later deploy one of these "Main" builds to the QA environment.
There may have been several builds of the Main branch since the last time QA have deployed. These builds are associated with the "Merge" changesets, not with the original changesets which were associated with the Tasks.
How do I determine the set of tasks which have been addressed by a given "Main" build, which is a build of a different branch than the one associated with the Task work items?
Once we've begun preparing for a release, we may very well need to make changes in the Release branch, which will complicate things further since we will be merging back from Release to Main, and the Release changesets will be associated with Tasks. Those will then be merged to Development, making life even more interesting!
P.S. The question "How to determine the work items associated with a source branch in TFS 2010?" comes close to asking the same question, but not quite.
Take a look at Jacob Ehn's blog post Automatically Merging Work Items in TFS 2010. He wrote a plug in that can be downloaded from codeplex. It will automatically associate the work items that were associated with the merged changesets. So when you merge to Main or Release the work items will be associated with the changesets in those branches, and the work items will be included in the build reports for builds off of those branches. The plug-in is super easy to deploy.
The other option is that you can build a custom workflow activity that you can run during your build that can traverse the merge history for each of the changesets that would normally be associated. It's essentially walking the tree starting with a known set of associated changesets. I would prefer this approach since you can let your developers worry about only needing to associate work items with the original changesets instead of having to also do it with merge changesets as well. This also allows you to get around having to deploy a custom work item policy as Bryan described in his suggestion.
I might have some sample code to get you started with traversing the merge history tree if you want to contact me at http://www.edsquared.com
We are planning to move from StarTeam to TFS for source control and are in the midst of refining our ALM procedures. Maybe I am misunderstanding something about how labels work in TFS, but it appears that you can apply a label to files by Changeset. I am trying to create a label on only the files/versions in the specific changeset.
I have attempted to do this like so:
1) Main Menu -> Source Control -> Apply Label
2) 'New Label' dialog appears
3) Leave path as is (Dev Branch)
4) Select 'Changeset' from 'Version' dropdown, enter my changeset #
5) Click Create.
... which results in the entire branch getting labeled. The changeset may be 1 - 100s of files, so individually labeling files is not practical.
We do this all the time in starteam: label changesets related to features, then move a build label up onto the labeled changeset. Am I missing something fundamental? (Thanks for any guidance)
Note the name... you are labeling by changeset not labeling a changeset.
Labeling in TFS is like marking a point in time. So when you label by changeset you are basically saying this is what my source control looked like at this point in time.
It sounds more like you area saying you want to be able to find a set of changes (changeset) not everything at the point in time that changeset was made.
You could pick a branching strategy that would allow you to branch by feature. The downside of this is that it will involve a lot of merging.
Another options would be to link the changesets for any specific feature to a work item and then you will have a list of changesets that you will want to merge up once you have completed that feature. In 2008 this can be a little troublesome because merging changesets that are not sequential can be more time consuming than necessary. (meaning there are changesets in between on that branch not that the changeset numbers are sequential)
Fortunately, you can try out different branching strategies and as long as you think it through it isn't to tough to switch if you don't like how you were doing it.
In TFS2010 I tested adding lables to a changeset and I am seeing the same behavior you reported.
When reviewing a changeset it will only contain the files that were checked in.
When reviewing a label that was created on the same changeset it will contain all of the files in the branch, with each file showing the changeset version of the last check-in.
I don't know why it works this way.