We have a "Main" branch and a "Dev" branch in source control; pretty common approach where developers work off of the Dev branch and merge changes to Main at set periods when the code has been unit tested and is ready for customer testing.
We link Work Items like PBI's (Scrum) and require comments on checkins. Normally the TFS build report will show the attached work items and changesets. Our dev build (Dev branch) does indeed do this.
But, our Main build which uses merged changesets from the Dev branch doesn't "inherit" those links. If you read our Main build (Main branch) report it shows none of the original changesets; just the "Merged from Dev" one.
Does anyone know if it is possible to make TFS look though the branches for all of the changes from the merges and put those in the build report?
What you are looking for is only available in 2010 I believe.
Related
We are using TFS 2010.
In 2 branches I have file that is clearly different in each branch. When I compare branches this file is displayed as different, but reconcile option is grayed out. If I try to merge, I get message that there is nothing to merge. Can somebody please shed some light here? Thanks.
For those willing to read more, here is the scenario I am facing often and I don't know how to deal with it:
There are 4 branches:
- Main branch
- Release branch (child of main branch)
- Developer1 branch (child of release branch)
- Developer2 branch (child of release branch)
Developer1 and Developer2 made changes in their branches and merged code to Release branch. In meantime, changes were done in Main branch (Urgent Fix or whatever). When changes are deployed, I made attempt to merge code to Release branch. Merging proved to be difficult as there were too many code conflicts at this point. So I made decision to take source branch (main) when resolving differences (that removed all changes made by Developer1 and Developer2 from Release branch). Now, I would like to ask Developer1 and Developer2 to merge their changes again and resolve their own conflicts. But, they can't merge, nor reconcile.
After you compare a server folder and a local folder, you can reconcile the differences between the folder contents and between files that have conflicting pending changes in your local folder.
You should also meet below required permissions
To perform these procedures, you must have the Read and Check out
permissions set to Allow. For more information, see Permissions and
groups reference.
More details take a look at this official tutorial--Reconcile differences between two folders
A step by step process show hot to use reconcile command, you could take a look at this reply here: How to have TFS 2010 detect changes done to files outside of Visual Studio?
We have lots of feature branches, and we don't want to manually create a build definition for each of them for continuous integration.
Is it possible to create one build definition in TFS Build 2015 that will build solution from the branch when code is checked in to it? We are using TFVC for source control.
Preferably, only the active branches should be downloaded to the build agent, as we have a lot of old branches that don't get any check-ins.
There is a similar question about old TFS Build system, but since build system was completely changed in TFS 2015, the answer would be different too - TFS build, one build for many branches
Short answer: No.
This works for Git, not for TFVC, unfortunately.
Actually, it would appear to work out of the box with TFS 2015 Update 2, according to a test I just ran with the following simple structure...
$/Project
$/Project/Product1/Solution1/
$/Project/Product1/Solution1/solution1.sln
: (and everything below it)
$/Project/Product1/Solution1-branch/solution1.sln
: (and everything branched below it)
$/Project/Product1/Feature2/another-solution1.sln
: (and everything below it)
Build settings:
Build tab | Solution should be "**\*.sln", Repository tab | Repository should be "Project" and Mappings should include "$/Project/Product1/".
The ** in the Solution field causes it to search recursively for *.sln files, which it then builds in sequence.
I just tried this and it built all branches one after the other.
Excluding "old" branches might be more difficult if you use the single recursive approach, but you could always simply list the desired branches in the Mappings area - the nett result should be the same.
Hope that helps.
If I understand your question, this might work for you.
This will build all feature branches, plus the develop (default) branch as part of CI.
Not sure why, but if you reverse the order of these it does not work.
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
Currently we have a branch structure like this: Develop --> Release. I want to change it so that it looks like what the TFS Branching Guidance document calls "Basic Branch Plan". It looks like this Develop <-- Main --> Release.
I was going to do this:
Rename Develop to Main (creating Main --> Release)
Creating a branch from this Main reusing the "Develop" name (creating Develop <-- Main --> Release)
Will I have problems with TFS reusing an old branch name for a new branch? Know any gotchas or things to look out for?
Additional Info
I did this in a test instance creating test branches without any files, pending changes, history, etc. (not a good real test) and TFS let me do the rename and branch without difficulty. However, I won't feel comfortable with this unless I can take our production TFS project collection, restore it in the test instance, and test the rename/branch on real data. There is a lot of history and branches there and I don't know what will happen. As noted in the answer, there are other considerations before doing this.
I'm preparing to do similar steps (except I'm moving subfolder locations of both parent and a child while grandchildren stay put.)
QUESTIONS:
When are you planning the rename?
Are there any child branches under Develop branch that you didn't mention?
Do you have any shelvesets against Develop that might be impacted by the rename?
General answer: Proceed with caution. From my reading branch renaming in TFS2010 can cause a few unexpected side effects. TFS will be doing the following steps (under the hood) for your scenario:
Rename Develop to Main ==> Branch Main branch from Develop, then delete Develop branch
Create new "Develop" branch from Main
I recommend reading the following posts:
Renaming Branches in TFS 2010 (ChandruR’s Blog)
"MSDN Blogs > ChandruR's Blog > Renaming branches in TFS 2010
So my recommendations for this case:
Avoid renaming branches - a cleaner solution would be to, at the right point in your release merge all changes to a parent branch and then re-branch to create a new branch hierarchy.
Or for the brave of heart :)
You will need to time the rename of your branch, to a point in your release where you can merge to all related branches. The steps to follow are:
..."
Renaming branches in TFS2010 - But it works on my PC!
“In TFS 2010 behind the scenes a rename is actually a branch and delete process, this meant we ended up with the new branch, but also a deleted branch of the old name. This is not obvious unless you have ‘show deleted items in source control explorer’ enabled…”
"Now implemented as a branch + delete behind the scenes (new name is branched from the old, then the old name is deleted). This allows traceability in History, but allows us to get around the problems with merging renames (see Add, Rename, Add scenario). "
.
RANDOM THOUGHTS
Get all devs to merge (or abandon) all safe changes in child branches of Dev. Also prune any inactive branches before the rename.
Read above articles.
Search to find the page (that I haven't found yet) that describes exactly what will happen in simpler terms based on real experience.
Specifically I'd like to know what happens to shelvesets on the Develop branch after it is renamed to Main. (Next step can answer this.)
You might consider making a "Sandbox" Team Project (or Team Project Collection) then try out your scenario to see if there are major issues.
Pick right timing (see link#1) and go for it.
Check history, do a merge between the renamed branches, check history again.
Allow developers back in.
Good luck, and post back with any new information (including your end results)! -zs
I have a Team Project in TFS where tasks are submitted daily. I would like to work on each task independently and then merge it into the main line after testing.
Currently there is a MAIN branch and a DEV branch which is a child of MAIN. Changes are worked on in the DEV branch and then merged into MAIN when they are ready. This is done via a "cherry-pick" merge. I've been reading everywhere that cherry-pick merges are bad and you should avoid them whenever possible.
I am having trouble wrapping my head around branching and merging in TFS and was wondering if anyone had any suggestions on how to achieve this goal in TFS without having to do cherry pick merges.
Any help is appreciated.
If I left out any key information please leave a comment and I will edit my post.
I think this Codeplex documentation will be a big help:
http://tfsbranchingguideiii.codeplex.com/
The download has several PDFs that outline different scenarios and strategies and give excellent Q&A on different approaches.
The key for your scenario would be to merge all changes up to a specified version from Dev to Main. Run all tests each time code is checked into Dev (and developers get the latest Dev code, then run all tests before checking in). Ideally, if the build in the Dev branch is successful after Dev checkin, merging into Main would be a good idea. Merge frequently from Dev to Main, and run all the tests in Main after each checkin.
So even though developers work individually on specific pieces, once they check into the Dev branch they are essentially saying "this code is ready to integrate." And when merging from Dev to Main, you no longer deal with specific pieces--you merge the whole enchilada. If Developers need source control for work-in-process code, they should use TFS shelvesets and wait to check into Dev until they are "done."
You might find Timpani Software's MergeMagician tool interesting. It is a branch management and automated merging solution that works with TFS (and also Subversion). You create publish/subscribe relationships between branches, and then the server automates the merges.
MM can be used to implement all of that patterns discussed in the TFS Branching Guide that Shawn mentioned.
FYI, it is a commercial tool. I don't know of any open source tools that do anything like this that work with TFS.
Check it out at http://www.timpanisoftware.com. There's a good overview video on the home page.