While I am rebasing our branch, rest of the team continues working on code. Rebase lasts about 1-2 hours. I'm doing it from merge in context menu when you right click the folder to merge, so nothing special here.
Team members check-out code, alter it but they do not check in. What risks this approach has? What is the best practice for this situation? How your team handles such cases?
I think what you're suggesting is a fairly standard approach and just to make sure I understand the question, here is a scenario.
There is a Main branch. From this Main branch 2 development branches have been created (devA and devB) these branches will be used to make changes to the code for 2 seperate projects.
The development in devA has reached a stable state and has been merged in to the Main branch. Now you want to merge the changes from Main in to devB
In devB the developers have been coding changes and have a number of files checked out. You don't want to make the developers check in their changes to devB and you don't want to initiate a code freeze whilst the rebasing takes place.
If the developers have been checking in changes to devB on a regular basis since the branch was created, you will porbably see merge conflicts when you try to merge the devA changes from the Main branch. Someone familiar with the code and requirements for both "projects" will need to help resolve those merge conflicts. Once the conflicts have been resolved you'll probably want to check that the code compiles and that any unit tests run and pass. If you have compilation errors or unit tests fail then this will need investigating.
Once you're happy that the merge from Main to devB has been sucessful then the developers with files checked out in devB can start to check in changes. If the files they have checked out were not changed as part of the merge from Main then the files will check in as normal. If however they have files checked out that were updated as part of the merge, TFS will bring up the merge conflict resolution tool and the developers will need to resolve any conflicts before they can check in the code.
Hopefully the above is resaonably close to the process you're currently following? If I've missed anything, or missed the point entirely then let me know.
This isn't as nice as it could be, but it's a common approach and one that we use.
The risk to this approach is that you could end up spending a lot of time fixing merge conflicts, especially if you have a large codebase with a lot of developers changing the code in a lot of branches.
To mitigate any problems, it's best to rebase as early and as often as possible. Early because if you save everything up till the end of devA's project, then the changes could have a significant impact on devB. Often because the number of conflicts per merge is minimised, making conflict resolution simpler and less error prone.
Setting up a "continuous integration" build will also help as you'll see compilation problems sooner rather than later. If you're using TFS 2010 then Gated Checking may also be helpful.
I'm not 100% sure that this answers your question so let me know if I've missed anything
Related
Do you really need a Branch to CheckIn / CheckOut Code in TFS i.e, just add files to a folder ?
What would be advantage to Branch in that case ?
You do not need a branch to check in and check out.
Branches however provide you with the ability to make changes to more thank one version of your code at once. Lets say that you have one folder at $/ProjectA/MyAwesomeApplication/Master. You can happily work away, checking in and releasing. At some point you find a bug in production that needs fixed immediately. However MASTER is well beyond what was last released and you don't want to deploy those changes yet.
You know which build is deployed and thus which changeset. You can branch MASTER at that changeset (the past) and create $/ProjectA/MyApplication/QuickFix. There you can fix that bug and ship, then merge back into MASTER and delete that branch.
Now obviously this is expensive and time consuming. A better way would to move forward and just ship what is in MASTER. If you have feature flags and good testing them you should be able to do that. There are however always those exceptions to that rule, and that's where branching comes in.
If you are using Git in TFS rather than TFVC the story is different.
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.
I recently migrated from VSS to TFS 2010 and I've been absolutely loving it, but there's something I haven't yet been able to get working the way I think it should.
GOALS
I'd like to quickly know when a change to Development breaks a build. If we find out after-the-fact, it's no big deal. Since a lot of check-ins happen throughout the day, we don't want to wait on the build to finish, so it should be asynchronous.
With our Main branch, I'd like to ensure that any time a merge happens into it, we make sure it's not going to break the build. I want immediate feedback on this. The wait time is fine, since we won't be merging into Main often.
CURRENT SETUP
My solution is under a folder called Main. I've made a branch off of that called Development. The workspace I'm working in is tied to the top-level, which includes both Main and Development branches. I tried adjusting my workspace to only point to Development, in case that was the problem. That didn't seem to fix my issue, so I set it back to the way I had it originally -- with both Main and Development.
Within the workspace's Build definitions, I have two definitions defined -- one for the Main branch and another for Development.
The first definition is for building the Main branch. It has a Gated Check-In trigger and "Items to Build" points to the solution file within Main.
The second definition is for building the solution in the Development branch. It has a Rolling Builds trigger and "Items to Build" points to the solution file within Development.
RESULT
Currently, when a change is made in Development and a check-in is performed, the gated check-in to Main is triggered. This not only causes confusion, but it also tends to slow down our overall process.
NEXT STEP
I've looked at some of the TFS guides to branching, general TFS usage, etc. Unfortunately, I haven't yet found a solution to my issue. If you've run across this issue before, I'd appreciate any suggestions you can give.
I'm not 100% sure at the moment, but the build should be triggered by check-ins into the part of the source tree that is covered by the build definition workspace.
So please have a look into the build definition and see what part of the source tree each build definition gets. Your CI build should only get the Dev branch, the gated build should only get the Main branch.
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.
I haven't found any good explanation of this problem, so I'm hoping someone can shed some light on it. My thought is that this is "just the way it is", but I would like to understand a little better anyways.
Here is my situation: I have a main branch, and a development branch(dev). Most developers are working in Main, but for my specific project I am working in Dev. I want to keep the code in Dev as much in sync with Main, so I do frequent merges into Dev.
The first time I merge Main->Dev, it copies file F1 which was changed in Main but not in Dev. This is great. The next time I merge Main->Dev, F1 has changed in Main again, so it should copy it (was not changed in Dev).
However, TFS tells me that both target and source have changes, even though the changes in target are exactly the same changes from Main. When this happens to a lot of files it is very cumbersome to go through and auto merge only these files.
Does anyone know why TFS does not do a better job with this situation. Does anyone know how to make merging easier in my situation?
thank you.
This definitely is "Not the way it is". I have never seen this happen the way you describe. Seems there must be something amiss in your environment or the way you are working.
This does not answer you question, but I would question why "most" developers are working in Main. Main should be for stabilization and as such very few people would work directly in it; only those doing break/fixes. New coding is always done in Dev and merged to Main.
Maybe you could layout your project structure and that might give some more hints what the problem might be.
After some testing and a few more merges, I concluded that this is "not the way it is". I could not reliably reproduce the behavior I originally observed. During subsequent merges, I did not run into the same difficulty but there was still some odd behavior I can't totally explain (not sure why I had to manually resolve conflicts when there were none in some files).
So I can't say TFS merge is deficient in any way, but there is something odd about it.
thanks.