I have a release branch (RB, starting at C5) and a changeset on trunk (C10) that I now want to merge onto RB.
The file has changes at C3 (common to both), one in CS 7 on RB, and one in C9 (trunk) and one in C10). So the history for my changed file looks like this:
RB: C5 -> C7
Trunk: C3 -> C9 -> C10
When I merge C10 from trunk to RB, I'd expect to see a merge window showing me
C10 | C3 | C7 since C3 is the common ancestor revision and C10 and C7 are the tips of my two branches respectively. However, my merge tool shows me C10 | C9 | C7.
My merge tool is configured to show %1(OriginalFile)|%3(BaseFile)|%2(Modified File), so this tells me TFS chose C9 as the base revision.
This is totally unexpected and completely contrary to the way I'm used to merges working in Mercurial or Git. Did I get something wrong or is TFS trying to drive me nuts with merging?
Is this the default TFS Merge behavior? If so, can you provide insight into why they chose to implement it this way?
I'm using TFS 2008 with VS2010 as a Client.
I had some similar initial struggles with TFS branching and merging (We have dev, integration, and main branches).
Short version is that you cannot merge directly back from a tip to a common ancestor.
So if C3 was branched to C5, then C7 was branched to C9, what the tool is providing makes sense within the context of how TFS works. You essentially need to go from C10/C9 to C7 then from C7 to C3.
To put it a different way with a more concrete example, here's how we handle multi-level branching and merging in our projects.
We start with trunk/main.
We then branch to an integration branch.
We then (and this is key) branch from integration into our individual dev branches so we can work on upcoming releases.
As changes are complete in a dev branch, we first reverse integrate by merging from integration to our dev branch (so we pick up everyone else's changes). We then forward integrate by going from our individual dev branch to the shared integration branch.
Once integration passes QA, we then reverse integrate by merging trunk to integration (just in case there are any hotfixes in main), then forward integrate all of the combined changes in integration down to main.
On release day, we do one last branch from main into a new release branch which we then deploy.
Basically, in TFS you always have to go up and down the branching/merging tree from trunk to limb to branch to leaf - you cannot at any time bypass any step in the branch heirarchy.
Metaphorically, TFS branch and merge is more like as sloth crawling up a tree and slowly down to the end of a branch without ever letting lose it's grip vs. a monkey hopping between branches ;)
Takes a bit of getting used to, but once done (and especially once you're used to the forward integrate/reverse integrate paradigm) it works a treat, especially when you have several folks all doing development and you need to wrap up everyone's changes without having things stomped over.
Hope that helps!
i was looking around this site before and came across to this page, is this helpful?
How to branch and merge in TFS
I think you might have a wrong merge methodology, because what you describe is completely possible, and it works for me. But you always have to remember when you start branching off the main branch is to do proper RI (Reverse Integration), and FI (forward integration). Have a search on codeplex for branching guidelines and best practices.
In essence, any changes that is dropped back to the main branch have to be RI'd back onto your other branches before merging it back. This is best practice and works every time, after that, you can continue to FI from branch back to main trunk.
Related
I am new to TFS and trying to figure out how to get my new rewrite of an existing application into TFS properly with Branching...
I have a project where I have three branches Dev Main and Prod
I just created a new branch off the Dev called Dev-branch-Rewrite I was able to get my code into the Dev-branch-rewrite but it doesnt show the main as being a branch I can merge to. I have done something incorrectly. Not sure what I am doing wrong
TFS forces a strict branch hierarchy, so you need to plan ahead. Currently I suspect that main is the parent of both dev and prod so in effect to go from dev to prod you have to merge via main.
The best practice would be to take the new branch for your rewrite from main this way you have a clear path to prod once the rewrite is done, but you can still support your users in the existing dev branch.
I.e
Prod
|
Main
| |
Dev Dev2.0
As a side note, I'd try to keep your branch names as short as possible as you may start to hit the windows 260 character path limit.
For more information on branching strategies, read the ALM rangers guidance on codeplex.
We have our development branch that has multiple revisions of our code. So it looks like:
Development
R1.0
R2.0
R3.0
Rx
We are working on multiple releases simultaneously. So, team A will work on R2.0 while team B will work on R3.0. While team A is making changes in R2.0, we need to make sure these changes are reflected in R3.0. Is there a way to require a developer to check in a file to R3.0 if he/she is attempting to check a file in to R2.0?
Edit 8/1/2013
After reading several articles on branching and merging strategies, I have an idea of how we should approach the issue. I just want to run it by you and ask if I'm headed in the right direction. So, instead of having the development branch and copies of releases, we should have a main (development) branch, and then branch off of it each release. Then, as frequently as defined in our branching and merging strategy, merge the changes in our R1.0 and R2.0 branches back to the main. And when we want to work on R3.0, we do a fresh merge of everything R1.0 and R2.0 to MAIN, and then create a new branch from MAIN. Then, say we need a hotfix to R1.0, we create an R1.1 from R1.0 and merge it back up to R1.0 then to MAIN, then from MAIN to R2.0 and R3.0. As we work on new releases simultaneously, we keep MAIN only as current as our next release. So if R1.0 has been released already, then MAIN should be kept up to date with R2.0 branch since it will be the next release. Please correct me if I’m wrong and point me in the right direction. I am new to branching and merging.
You should be using branches to manage the changes between verisons, not having different version of the same code in the same branch.
i.e. R2.0 and R3.0 are both child branches of your main (or trunk) branch. You can then merge changes from R2.0 to Main to R3.0
Read the ALM Rangers guidance for more information on Branching Strategies
I like your idea and I think it will definitely handle your problem. We are doing something similar except that we have a merge branch(Intermediate branch) in between Main and the Releases.
Main -> Intermediate -> R1
Main -> Intermediate -> R2
Main -> Intermediate -> R3
The advantage of this option is that:
You dont have to bring in all the changes to Main (trunk) and Main will stay clear and will act as your GOLDEN production like code.
Adds another layer of protection to your golden code. Let's say, the R3 branch was just created from Intermediate, but at that point R2 decided to scrap its release. In this case, if you go with the intermediate branch (which has R1 + R2 at this point) then you can just delete the intermediate branch and branch off from Main( which has only R1) to create a new Intermediate (instead of rolling backing the changes with your approach). Then start off with a new R3.
Just my$0.02
When making a deployment to production, should I mark my code with a label or create a branch for the code that's in production?
In TFS, I would have a Release branch with a label identifying the specific version being released to production.
Which would imply you have other branches may I suggest the following
Three major branches: Main, Develop, & Release.
One Hotfix branch for your current fire.
0 to N Major-Feature branches to contain the disruption of development.
Details
Main Branch
Contains the latest stable builds
Tag/Label each release
Develop Branch
Branched from the Main
Where most of the work is done
Merge back to Main before release
Release Branch
Branched from one of the following:
The Develop branch
OR the Main branch (this may be better since it is "stable")
Bug fixes are done here
After fixes are tested and released,
merge to Develop branch
OR merge to Main branch and then forward integrate (FI - which is a merge from parent to child) to Develop
Tag/Label each release or bug fix
Hotfix Branch
Branched from Main
Merged back into Main
Forward integrate merge to Develop
Used to allow Main to remain "stable"
Major Feature Branches
Branched from Develop
Merged back into Develop
Used for major features that would possibly disrupt the regular development path
References:
another stack overflow question: when-to-use-a-tag-label-and-when-to-branch especially Martin Woodward's answer
Source Control How To by Eric Sink
A successful Git branching model by Vincent Driessen
This contains a very good graphic of a branching model
Ideally, both.
You probably want to have a label so that you know exactly what you delivered for a specific release. However, you probably also want to create a branch so that you can perform minor bug fixing to what was released and create a new release.
In practice, you could approach it in one of two ways:
Have a continuous developmental timeline that gets branched for each of your production releases:
example:
------------------------->dev
| | |
| | |
| | |
v1.0 v2.0 v3.0
Have your production releases "cascade" off of one another:
example:
---->v1.0---->v2.0---->v3.0
Ultimately, up to you in deciding what architecture to adopt, as long as it's consistent and makes sense to you.
You can use a combination of both. Here is how we do this internally for all projects.
We have structure with folder Branches and sub folder for each minor and major version. We also use labels that we set on individual sub folders so we can easily rebuild any specific version any time in the future.
$\Branches
\2012.01
\2012.02 (branched from 2012.01)
\2012.03 (branched from 2012.02)
\2013.01 (branched from 2012.03)
You can also check out Visual Studio Team Foundation Server Branching and Merging Guide for more details.
I have seen both done, Labeling is more lightweight and to me easier. But, it has been pointed out that labels can be deleted rather easily. A branch protects against this by not actually being deleted unless "destroyed". The reason I prefer not use branches is I hate having to cloak them as I tend to do get latest from the root and don't want all those branches filling up my hard drive
For the record, since it was pointed out to me about label's being deleted I have removed permissions for Labeling from everyone but Admins and the build service accounts to help mitigate this.
I have the Development branch forked from the Main branch.
Could I merge the Development branch back to the Main so that Main branch code would be equal the Development branch?
What is the most safe and reliable solution for this?
The easiest way I've found to do this is to do a merge using Visual Studio and the Source Control Explorer.
In the Source Control Explorer, right-click on your development branch and select Branching and Merging > Merge
In the Target Branch drop-down select your trunk ("Main") as the destination. This is likely the default selection if you've branched from Main originally.
There are two options:
All changes up to a specific versions: You choose based on a revision and merge it all up to that revision in one fell swoop. If you have a lot of changes, this can save you some time, but also is riskier in terms of resolving conflicts if there have been a lot of changes in Main.
Selected changesets: You select single or groups of changesets to merge back and then repeat this process until you've merged back what you need. Less risky option, but much more time consuming. I personally prefer this approach so that I can see the changes going back into the trunk and know what to expect as changes.
TFS will instruct you if there are merge conflicts while you are merging. This occurs when you change something in the trunk after you've branched to your development. If one of the changes you've made in development conflict with the changes you've made in the trunk, you will have the chance to resolve this in Visual Studio.
If you do not have any conflicts, your development changes will move into the Trunk and simply merge with the changes you already have there.
I admit one work place they merged the Trunk to the Branches, but its not supposed to work that way.
The generally accepted method is merge the Branch back into the Trunk.
It sounds like you are working in the Trunk ("I can create some additional folder or additional files in the trunk") and wanting to merge into the Branch.
I recommend doing it the standard way: only work in Branches merging back to the Trunk, never coding directly in the Trunk.
Simply put I have the following branch setup:
MAIN
|--- DEV
|--- PROD
Most developments are done in the DEV branch. When the code is ready to test, everything is merged to the MAIN branch and published to our test environment. When tests are completed, a merge to PROD is done and everything is published to the production server. Every now and then changes (mostly bugfixes) are made on the MAIN or PROD code, but this is an exception.
I have been asked to think out a system for feature and bugfix merging. This means that separate changes in the DEV should be merged across MAIN and PROD. With our current setup this information is lost: for example features A, B and C are implemented in the DEV branch. Let's say every feature has two corresponding changesets: A1, A2, B1, B2, C1, C2. With our current way of working, everything is merged to the MAIN branch in one go. So when we want to "cherry pick" features which have to go from MAIN to PROD we can't do this because there's only one changeset on MAIN: the checkin of the merge.
How would you fix this? Do I need to change something to my branching strategy?
I'm using TFS for source control.
So when we want to "cherry pick" features which have to go from MAIN to PROD we can't do this because there's only one changeset on MAIN: the checkin of the merge.
You can write a tool to piece through the merge history, if you like, but the real answer is don't do that. When you cherry pick, you lose any guarantee that the code you tested and stabilized in the source branch will perform the same way in the target branch. Sometimes that's ok, but in your case it defeats the whole purpose of having an intermediate branch sitting between raw untested Dev checkins and your live PROD deployments.
As discussed in my favorite branch/merge video, your guiding principle should be "merge down, copy up." That is, whenever the need arises to deconstruct and/or apply code diffs, let unstable branches take the hit. (Cherry picking features out of an otherwise integrated app is one example.) Meanwhile, code that's promoted up toward stable branches like Main & Prod should always be a straight copy that matches what you've already worked so hard to stabilize in the source branch. Sounds like you're following this strategy currently; preserving it in the face of cherry picks would be my #1 motivation for using feature branches, even moreso than insulating feature teams from each others' breakages.
Managing dependencies between features is an issue, as Jim mentioned. If you can identify them in advance, the usual solution is to make sub-branch(es) that are shared by the features with the common dependency.
Feature1
\
LibA---
/ \
Feature2 \
DEV -- MAIN -- PROD
Feature3 /
\ /
LibB---
/
Feature4
Software doesn't always go as planned, of course. And this doesn't work at all if the branches that need to share code are on opposite sides of the tree (e.g. if Feature1 depends on LibA and LibB, but Feature2 is ill equipped to be part of B for structural or technical reasons).
I don't think there's any magic sauce here, you've just got to find a system where you have a revision on main for each unit you might like to cherry pick.
This can be done trivially by merging each revision individually, which is a pain, but gets you what you want.
Alternatively, you can up the granularity, by merging each feature into main one at a time. This requires that you work sequentially on features, which may be ok if you're on your own, but will be a pain if there's a few of you, since you'll have to go through a code freeze where some people have finished and others haven't.
Another way of working which you may or may not find more manageable is to have a DEV branch for each feature. In this sense, instead of having an ever existant DEV branch, have a collection of ephemeral DEV branches that only exist until the feature is completed.
The reintegration of each DEV branch will give you a clear revision in main which can be cherry picked.
You can get dependencies between dev branches. Say branch devA needs some implementation from branch devB, you'll have to merge the required parts of devB into main and then merge them down into devA. However, devA shouldn't be needing unfinished work from devB, so you should (in theory) be able to RI those parts happily anyway. And of course, since you're cherry picking into PROD, these partial integrations don't have to get published.
Given your branching strategy, I guess you've already found this, but if not, it's worth reading:
http://branchingguidance.codeplex.com/wikipage?title=html&referringTitle=Home