Our Solution is big, with many Projects and files. Our branch has about a dozen changes, but the files changed are spread confusingly across the Solution.
Conveniently, TFS can compare two branches and show you just the dozen changes. This is handy to get your head around just what changed and ignore the rest.
However, from that dialog, I do not see a "Merge" option. As a result, in order to merge the dozen changes we still need to spelunk through the Solution.
Is there an easier way? Surely there must be.
Normally you would merge an entire branch - the TFS engine is clever enough to only change what has actually changed.
Related
I have some business reasons for wanting to do this but I won't get into those. Basically I have a Team Project with a single branch(I know this is bad) that I have been working on for 6 years now. It has a large number of change sets. I would like to merge first couple thousand change sets into a single one. Is this possible?
All the information on merging change sets seems to be focused on multiple branch situations.
Which you mean is more likely changeset compression. Just like using git squash commit command to clean up local commit histories.
Unfortunately, this is impossible. For now TFS can only merge continuous changesets or single changesets. If this can be done how to handle the changeset history.
TFS to merge multiple, non-continuous changesets.
Thanks for the feedback on this idea. We have reviewed this feedback
and determined that we will not be able to complete this suggestion in
the foreseeable future.
Matt Mitrik TFS Program Manager
You may have to create a independent branch for handling this situation.
Simple question perhaps, but one I'm having a hard time finding the answer to. I often work at a client that uses TFS as source control and they completely avoid using the baseless merge feature of TFS source control
In part because in the past it required a command line tool to do it, but possibly more important because when you do it now in the interface it shows you a yellow exclamation warning symbol that you are indeed performing a baseless merge.
This sort of scares them off and makes them avoid it altogether. I've been searching around to figure out if there are any specific risks involved in baseless merges but I'm unable to find that out (or details on how baseless merges work underneath the hood)
Baseless merges should be avoided if at all possible. When you do a baseless merge, unlike a merge, you are disregarding the history of either side. Indeed you can merge two branches that are totally unrelated—and that can be dangerous.
The key is to create a branching strategy that allows you to not have to use that feature.
We have a development branch where the developers check in their workspaces when the a task is finished. They label the check-in. Let's say 3 developers, with labels 1, 2, and 3. Now I want to merge just Label 1 and label 3.
My question is, won't label 3 have all the code from label 1 and 2, also?
It seems to me there is no good way to omit label 2 from the merge.
You are correct, labels include a crosssection across the codebase (though since they're scoped they might not include all files technically). The only way to merge Label 1 and 3 is to look at the respective change sets and select the ones to merge, this process is called cherry-pick-merging. If the changes are neatly combined into a set of consecutive changesets, then this might work.
You can look at the Changeset number that belongs to the files you want to merge in that label (there might be multiple changeset versions associated to a label) and merge the specific changesets.
Relying on cherry-pick-merging is dangerous, since it can be very hard to actually merge two changesets without taking additional changes that happened in between. Either you'll accidentally take too much into the target branch, or the changesets rely on changes in other changesets which you might not be considering to merge.
Unless the team is fully aware that the changes are going to be cherry-picked and develop with this in mind (shelving, checking in working features as single changesets, applying design patterns to check in separate modules that can be easily merged with existing functionality), then it's safer to merge up to a specific changeset or to use feature branches.
Another technique to selectively 'merge' features is to put feature-toggles in your code. Essentially allowing you to release feature 1+2+3 with feature 2 turned off.
We are considering using Gerrit for the large project. At this point it would be interesting to know how people are dealing with merge conflicts of approved changes.
Imagine, that many changes of different size are pending revision simultaneously, and they are being reviewed and verified gradually. Since some of them might be modifying the same piece of code, the conflicts are inevitable. It is not a problem if "integrator" accepts patches manually in a simple workflow, small conflicts can be resolved on the way, but with Gerrit things are different. When the change has been reviewed and approved, in case of merge conflict, as I understand, it will need to be rebased by the author and pushed for revision again, in which case revision process starts again. In the relatively active projects, with more than 50 external contributor commits per week, this might turn into nightmare, if revision of the same patch might be required to be done several times due to merge rejection after each approval and submit, which seems to be not efficient.
Questions:
Am I correct that Gerrit is not a way forward for the large and active stuff where the large number of merge conflicts is expected?
Some merge conflicts can be trivial, is there a way to resolve them without the need of bothering author to recommit the change?
If the change needs to be backported to stable branch(es), I guess the separate change for each branch needs to be pushed for revision, even if the cherry-pick is clean.
General comments about your Gerrit workflow experience are also welcome.
Gerrit is used by some really massive projects, such as Android and the related bsp, kernel, etc repositories. These projects get way more than 50 external commits per week. I think Qualcomm will have several thousand commits in about that amount of time.
There is a setting in Gerrit to auto-merge trivial conflicts. This can be set per-repository. If this option is set, the change is merged in based on your submit strategy (cherry-pick, merge if necessary) after the change has been reviewed and verified and a user presses the 'Submit' button. The best documentation I could find for this is here http://gerrit-documentation.googlecode.com/svn/Documentation/2.3/cmd-create-project.html#_options under the --use-content-merge option.
Yes that is typically how we do things. There are other options (bypassing review, merging branches, etc), but cherry-picking to the needed branches and reviewing works well.
We want to keep our history clean and understandable, and therefore reasonably linear. So we have configured Gerrit to use only fast-forward merging. The only visible merges are for release and support branches (we're using git-flow) which makes things much easier to understand.
However, we have the trivial-rebase plugin installed so that previous review status is automatically applied to the rebased change. This happens regardless of whether rebasing is done in Gerrit (using the Rebase button) or by the developer rebasing locally and re-pushing the change.
In our experience, merge conflicts are actually less common in a large project, due to the much larger number of source files involved. We have around 16,000 files in the repo and 30 full- or part-time developers, so the probablility of editing the same file is quite low.
In any case, if two developers are making changes to the same part of the same file, they really should be talking to each other. If the project architecture requires frequent changes to the same file (eg a registration table of some kind) the architecture needs to be redesigned, to use something like dependency injection, or to generate that source file automatically from fragments as part of the build.
When we hit a merge issue at our company, the developer rebases and pushes to gerrit. If the merge was minimal, he's allowed (by convention) to LGTM the rebase and submit.
We are still debating if/when developers should rebase when updating patchsets. The UI gets confused when comparing between patchsets when the parent changes.
I'm using it for a few weeks after using mercurial for a couple of years with a feature branch merged into default mode and I'm hating gerrit. I find myself with more overhead solving trivial conflicts that are solved automatically by merges on mercurial or git in non-gerrit mode. Then everybody uses the argument android uses gerrit ergo gerrit is good and should work for everybody.
I am pretty new to TFS and source control. I unable to understand the advantage of branching. Since i can do the same stuff by creating 2 folder main and development, when I am done with development.I can merge the code using any diff tool with the main branch.
Then whats the point of having branches ? I know there must a huge advantage but i am unable to understand.
(UPDATE: TFS now supports git for version control so the rest of this answer no longer applies)
I would google branch-per-feature.
The main advantage of branching is that you can work on a feature and not be interrupted by anyone else's work. When you are ready, you can merge and see if many features work well together or not. This is usually done as the feature is developed but for small features can be done once the feature is complete.
The advantage is that you have a clear history of what you did to implement something. Without branches, you would have a whole lot of commits mixed together with other features' commits. If QA does not pass a certain feature, you have your work cut out for you to put together another build using just the commits for the other features. The other alternative is to try and fix your feature so that QA passes. This may not be doable on a Friday afternoon.
Feature toggles are another way to omit work but this increases the complexity of code and the toggles may themselves have bugs in them. This is something to be very weary of and see how this became an "acceptable" work-around.
Branches are also used to track changes to multiple versions of releases. Products that are consumed by multiple customers may be in a situation that one set of customers is using 1.0 of the product while others are already on 2.0. If you support both, you should track changes to each by branches that are designated to them. The previous points still apply to developing for these branches.
Having said that, TFS is not ideal at branch-per-feature for a number of reasons. The biggest is that it does not support 3-way merges - it only has what is called a baseless merge. The way history is tracked, TFS cannot show you a common ancestor between the feature branch and where you are trying to merge it to. This leaves you potentially solving a lot of conflicts. In general, a lot of people that use TFS shy away from branching for this reason.
3-way merges are great because they will show you what the common ancestor is, what your changes are and what the changes in the other branch are. This will allow you to make a very educated decision on how to resolve a conflict.
If you have to use TFS, I would suggest using git-tfs to be able to take advantage of 3-way merges and many other features. Some of them include: rerere, rebasing, disconnected model, local history, bisect, and many many more.
Rebase is very useful as it allows you to alter a feature to be based off of another starting point, omit commits, squash commits together, split commits, etc. Once ready you can them merge into an integration or release branch, depending on the workflow you decide upon.
Mercurial is also another one that may be easier to use, but will not be as powerful in the long run.
If you have the opportunity, I would highly recommend moving away from TFS for source control due to a lot of limitations when compared to modern day DVCS.
Here is a nice set of guidelines to follow if you want to effectively manage branching/merging:
http://dymitruk.com/blog/2012/02/05/branch-per-feature/
Hope this helps.
There is a lot of information to read through, but there is TFS Branching Guidance located here if it helps at all - http://tfsbranchingguideiii.codeplex.com/