We are using TFS2010 for source control, the source repository has 3 main branches; MAIN, REL and DEV
Consider this scenario:
Several developers are working in the REL branch (fixing shipping issues). As they work their changes are checked into the REL branch tested and subsiquently merged back into the MAIN branch.
When developers perform their merge (using the source code explorer in VS2010) if they pick the "selected changesets" option the dialog performs some sort of query and presents them with a list of candidate changesets that exist in the source (REL) branch that have not yet been merged into the target (MAIN) branch.
Given that there may be a delay between the DEV commit and the subsiquent merge we are finding people "forgetting" some changesets.
What I would like to do is create a work item query or Excel report that can reproduce the dialogs query results so we can add this to the projects SharePoint portal.
Specifically: given the current user, and a source and target branch name can I use WIQL or a Excel document to retrieve a list of changesets not currently merged into the target branch.
Can anyone tell if this is possible? and better still tell me how to do it!
The question TFS: List changesets that have not been merged asks a similar question but the aswer alludes to a "write your own code" solution, I would like to pull this off with the "out of the bag" tools; Excel or WIQL.
Take a look # this answer
How can I check which branches a TFS 2008 changeset has been merged into?
They outline the tf merge command to list the changesets that need to be merged.
When I had to do something like this I ran a command similar to the one in the answer above and fed it into a text file, with a little bit of tweaking, you could probably turn it into a .csv then open it in excel and filter it by user etc.
To my knowledge, WIQL is all about retrieving exclusively Work Items - so this aspect is a dead end.
Related
I made sweeping changes to 2 projects (call it Project A and B) in my team's repository in this PR *. After getting through testing, review, and getting comments resolved, I found out that a different team is working on conflicting changes to project A on a different PR and those changes need to go to staging first. Now I can't merge my PR because it has changes to A, but my changes to Project B need to be merged ASAP. Now the obvious answer is probably to abandon the PR, do a soft reset and start again with two branches, but my team wants to keep the comment threads on both A and B because they showcase a month of work and important design decisions made by multiple teams during the reviewing process. Is there a way to split my changes to Projects A and B into two separate PR's without losing all the comments?
My current solution is branch a new branch off the current one, manually undo my changes to Project A from the branch, push, and leave the comments to A dangling (I think there will be some comment view that the file reference is deleted), merge. Then create a new PR of the newest branch, copy and paste each of the 50+ dangling comments over to their respective files, resolve all, and merge. This is obviously not great because I lose some context and it will take hours. Other solutions I've seen on here will delete all existing comments altogether and I can't have that.
*Yes, I definitely shouldn't have done that.
There is no out of the box solution for this.
I would suggest to use Azure DevOps APIs, and even that isn’t a walk in the park.
Modus operandi
Choose your language, PowerShell, js, c#, etc and start exploring. Below a suggestion where to start:
Start with getting the original PR using the getbyid api
Since you mention the comments are the most import part, the next thing is to retrieving list with thread comments API.
Optional: Per comment iterate through the thread with the next get api, because the docs state: Represents a comment which is one of potentially many in a comment thread.
From this point, retrieve more info you need or start building the copy of the PR with, create PR and adding comments and other part you need to reuse.
Again, this is not easy and maybe retrieving and saving this in another format already helps you.
I did tried to find a solution for you online, but did find it (yet). Found other handy stuff like this quick and dirty js script to search through comments.
I'm trying to study TFS REST API, but to no avail it is just hard to understand what parameter is what in the sample request given in the documentation.
What i would ultimately like to do is retrieve a list of all the commits done in lets say a particular project that have a bug associated with them. I want to retrieve a list of all these commits but only the ones associated with a bug fix.
Can someone please help me with this?
Not sure which version control system you are using, TFVC or GIT. Assuming you talked about GIT since the commit mentioned in your question.
There is a related REST API to Get a list of commits. For what parameter is what, there are also a detail table with notes. Such as fromDate which stands for Start date to search from.
To retrieve the commits with bug fixed comment
To retrieve a list of all the commits in a particular project you could use the branch parameter. Usually should fix the bug in a QA branch or DEV branch.
GET https://fabrikam-fiber-inc.visualstudio.com/DefaultCollection/_apis/git/repositories/278d5cd2-584d-4b63-824a-2ba458937249/commits?api-version=3.0-preview&branch=master
Then you just need to filter the comment with bug keyword commits.
To retrieve the commits related bug workitem
It's more accurate and convenient. First you need to get the bug workitems in your project. Using Get a list of work items Rest API with specific field such as "System.WorkItemType": "Bug", "System.TeamProject": "Your project name"
GET https://fabrikam-fiber-inc.visualstudio.com/DefaultCollection/_apis/wit/workitems?ids=297,299,300&fields=System.Id,System.Title,System.WorkItemType,Microsoft.VSTS.Scheduling.RemainingWork&api-version=1.0
When you associate a commit with the bug workitem, TFS will automatically add it as a linked item in workitem specified. Then you just need to get a workitem with links and attachments.
Assume you already have the Bug ID, you can use Get a WorkItem with links and attachments api to get all the commits associated with the bug.
Here where I work we have a branch which is only used to check-in ongoing bugs and tasks. The small tasks are shelved and recovered in the next week, when they are checked-in.
We developed an auto-merge system where these small check-ins are all merged to all specific project Branches. Then, at the end of the project, it's reverse merged into the main branch, thus going automatically to another project branches.
But, suppose I have a branch with Feature A, and another with Feature B. I need a third, with both Feature A + Feature B + Bug Fixes. I don't want to reverse merge them as I don't want to mess up the main branch (yet)
I've created a branch from Feature A, and enabled my auto-merge from "Feature A" to "Feature A+B". So every bug fix goes this way: Main -> Feature A -> Feature A+B. And every checkin within Feature A goes to Feature A+B.
Now I want to do baseless merges from "Feature B" to "Feature
A+B".
Is there a way to enable merging between them (within TFS) ?
I know it blows hierarchy up, and I know I can just perform x baseless merges through tf.exe, or three-way merge the files manually (or using any known tool).
But I'm not responsible for doing this, it's another developer who got used to the Team Explorer interface and all, so it would make his life easier.
Now, now, I know a probable answer/comment will be:
"You need to revisit your branch structure, as something is wrong!"
If possible, put that with some tips, I'm currently trying to change that but I'm not sure what to do when we develop 2 separated projects that, all of a sudden, need to be put together.
Your assessment of the situation is correct, you will need to use a baseless merge here to establish a relationship between Feature B and Feature A+B. tbergstedt is correct that TFS will remember the merge relationship between the branches once it is established. So, that means you will only need to perform one baseless merge in this scenario and then the normal merge UI in Team Explorer will pick up subsequent changes.
Now, as far as actually performing the baseless merge goes, it will need to be done from tf.exe using the /baseless option UNLESS you have a Team Explorer 2012 Beta client. In Team Explorer 2012 we have added the ability to perform a baseless merge in the UI. If you don't have one, I would suggest that you just perform the first baseless merge and then left your co-worker do the subsequent merges using the UI.
-Taylor, TFS Version Control Development Lead.
As I understand it, once you have done a baseless merge between two branches using tf merge /baseless, TFS remembers this relation and from then on any user can perform a merge 'normally' between the two branches.
The catch is that the baseless merge probably will detect conflicts for every item, and you need to check in new versions of everything in order to create the relation between the branches for the items. So, using your branch structure and doing a baseless merge between FeatureB to Feature A+B, you must be very careful when solving the conflicts - if you simply select the target version, any FeatureA changes on the target branch will be overwritten with FeatureB!
I should add that I haven't done this all the way through; I had a similar scenario but bailed out when I realized that I needed to solve every conflict in detail. Our product is huge, so it wasn't worth the time and the risk for us.
I have made all my modifications in my branch and going to another branch(or main). I had given the detailed comments while I checked in my work branch. But with clearcase merge manager, I have to reenter the same comments again which is really tough. Are there some way to use the original comments of the corresponding source version of the element?
The ClearCase Merge Manager, based on cleartool findmerge shouldn't ask you for any comment, and perform all merges automatically (except for the non-trivial ones).
The merge manager wizards should allow you to merge automatically files and directories, and the merge comment should be a default one.
I have a set of work items that are completed and I am ready to move their changes to our production branch. Is it possible to find the changesets that are attached to them and selectively merge them with the target branch?
Not easily is the short answer.
Currently there is no real link between work items and code promotion. You can associate a changeset with a work item on check-in (or indeed at any time), but that is about as far as things go.
Basically you would have to do this by hand using the provided UI in Visual Studio (i.e. look up the work items, get the changeset ID's and then do (possibly several) merges by selecting the appropriate changeset ranges. If this is a regular way of working then you could write a program in .NET that used the Microsoft TFS API to talk to the work item tracking component to get the changesets required and then either did the merges programatically or kicked off the command line client (tf) to bring up appropriate UI for the merges.
Sorry it's not a more helpful answer. I know that the team at Microsoft have heard this scenario a few times now however I've not heard of any plans to have it better supported "out the box" in the current or the next release of TFS. That said, there are a lot of improvements to the branching ad merging stuff in TFS2010 so it is possible that something is/will be in there that might help you. It may be worth you logging some feedback on http://connect.microsoft.com/VisualStudio for this feature if it is important to you.
Good luck,
Martin.