As a follow-up, strategy #2 seems to describe what my team is doing: http://blogs.collab.net/subversion/2007/11/branching-strat/
leojhartiv wrote: > > Thanks for your responses! > > I guess the part I'm missing is how you would support hotfixes, etc? If I > don't always branch off of trunk (production), how can I be sure I'm only > releasing the small changes to support the hotfix, versus all the other > changes being worked on for a larger development release? > > > Varnau, Steve (Neoview) wrote: >> >>> -----Original Message----- >>> From: John Maher [mailto:[email protected]] >>> Sent: Monday, February 20, 2012 5:37 AM >>> To: Varnau, Steve (Seaquest R&D) >>> Subject: RE: Branching/Merging Strategy >>> >>> >>> Hello >>> >>> I'm new to subversion and have two questions. >>> >>> 1) How do I properly make a post? I get these e-mails but no where do >>> I see any information on how to put a post up. >> >> Just mail to [email protected]. I've copied the list on this >> response. >> >>> >>> 2) I had a problem with a merge where code from one function had gotten >>> placed in another along with all kinds of other problems to the point >>> where I do not feel comfortable with the merge. It took a week going >>> through backups to fix the code. I would like to learn how to use it >>> without problems but something in the statement confused me. The >>> statement "A common pattern is that the trunk is for new feature >>> development" doesn't make much difference between using the trunk for >>> production and branches for future releases if the trunk and branch are >>> just labels that have no meaning. Or is there some hidden meaning that >>> I do not know about? >> >> The naming does not really matter. In my project, what we treat as our >> trunk is not really named "trunk". But that is the common terminology >> used in the list. >> >> The pattern of usage is the key thing, not the names. So one place where >> all the changes get integrated back together into a common source tree is >> the logical trunk, whether we call it trunk, branch/main, or bob. >> >> The original poster is using a pattern where the trunk is what is in >> "production". So when a feature is ready to go into production, they >> merge it in. I am suggesting that a more common method is the reverse -- >> when something is ready for production, branch it off. >> >> For instance, the subversion software itself has to support old releases >> that are in the field, not just one "production" version. So, features >> are developed on the trunk and when getting ready to release, they create >> a release branch. Fixes can be made on those branches, released, and >> also merged back to trunk for future releases. But the trunk is never >> synched (merged) back to those release branches. >> >> So in this model, there is a main line of development (trunk), and two >> kinds of side branches. Release branches and development branches. As I >> described above, release branches are not synched up to the trunk, but >> development branches are synched before they are reintegrated. >> >> Nothing magic in the naming, and subversion does not keep track of which >> branches are what types. It is just in the merging patterns used. You are >> left to keep track of that by naming schemes, etc. >> >>> >>> Thanks >>> Mar >> >> Hope that helps. >> -Steve >> >>> -----Original Message----- >>> From: Varnau, Steve (Seaquest R&D) [mailto:[email protected]] >>> Sent: Sunday, February 19, 2012 1:34 PM >>> To: leojhartiv; [email protected] >>> Subject: RE: Branching/Merging Strategy >>> >>> > From: leojhartiv [mailto:[email protected]] >>> > Sent: Saturday, February 18, 2012 8:36 AM >>> > To: [email protected] >>> > Subject: Branching/Merging Strategy >>> > >>> > I wanted to describe our branching and merging strategy and hopefully >>> get some feedback. We are using Subversion Server 1.6. >>> > >>> > Currently we manage trunk plus up to 3 other branches: >>> > * trunk: always represents "what's in production" >>> > * 1.0.0, 2.0.0, etc: represent long-term (normally quarterly) >>> development branches >>> > * 1.1.0, 1.2.0, etc: represent monthly maintenance branches >>> > * 1.0.1, 1.0.2, etc: represent "deploy immediately" hot fix branches >>> > Our process of creating a branch is to svn copy from trunk into the >>> new branch. So in the case of a new development branch: >>> > svn copy "http://myrepos/trunk"; "http://myrepos/branches/2.0.0"; >>> > Or in the case of a new maintenance branch: >>> > svn copy "http://myrepos/trunk"; "http://myrepos/branches/1.1.0"; >>> > When either branch has been deployed to production, we use a svn merge >>> reintegrate to merge it back into trunk. So in the case of the >>> maintenance branch: >>> > svn --accept p merge --reintegrate "http://myrepos/branches/1.1.0"; >>> "http://myrepos/trunk"; >>> > We then merge trunk into any future releases still pending and resolve >>> any conflicts: >>> > svn merge "http://myrepos/trunk"; "http://myrepos/branches/2.0.0"; >>> > This has worked well in most instances. The reintegrate option almost >>> never has any conflicts. However, when we got close to deploying 2.0.0 >>> we ran into trouble. >>> > 1 or 2 weeks before we were ready to launch 2.0.0, some of the team >>> needed to start work on 2.1.0 and 3.0.0 while others were finishing up >>> on 2.0.0. The normal process would be to create 2 branches off trunk: >>> > svn copy "http://myrepos/trunk"; "http://myrepos/branches/2.1.0"; >>> > svn copy "http://myrepos/trunk"; "http://myrepos/branches/3.0.0"; >>> > Unfortunately, this won't really work as much of the work on these >>> branches depends on completed work currently in 2.0.0, but not yet >>> merged to trunk (since we haven't gone to production yet). >>> > So what we did was create these branches off of 2.0.0: >>> > svn copy "http://myrepos/branches/2.0.0"; >>> "http://myrepos/branches/2.1.0"; >>> > svn copy "http://myrepos/branches/2.0.0"; >>> "http://myrepos/branches/3.0.0"; >>> > This worked fine until we started reintegrating 2.0.0 back into trunk >>> and out to 2.1.0 and 3.0.0. We've found that all of our merges are >>> missing change-sets and often report conflicts that don't really exist. >>> My guess is that branching off of 2.0.0 has confused subversion's >>> automatic merge tracking, but I honestly don't understand how all of >>> that works enough to be sure. >>> > >>> > My questions are: >>> > * How are other teams handling the above scenario? >>> > * Is there a different approach we should be using? >>> > Thanks for your help! >>> >>> The merge problems you describe (synching trunk to 2.1.0) can be done >>> correctly, but they are harder to get correct. You need someone who >>> really understands branching and 2-URL merging. I often have to draw the >>> branches on a whiteboard and identify the ranges/deltas that need to be >>> merged. >>> >>> That being said, your branch strategy may be making it harder than it >>> needs to be. Many times multiple versions of software may be in >>> production or supported at a time, rather than a single version in >>> production. A common pattern is that the trunk is for new feature >>> development, and then released software is branched off. Any >>> fixes/patches go on the side branch and also merged back to trunk for >>> future releases. >>> >>> -Steve >> >> > > -- View this message in context: http://old.nabble.com/Branching-Merging-Strategy-tp33348661p33366451.html Sent from the Subversion Users mailing list archive at Nabble.com.
