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:jo...@rotair.com] >> 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 users@subversion.apache.org. 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:steve.var...@hp.com] >> Sent: Sunday, February 19, 2012 1:34 PM >> To: leojhartiv; users@subversion.apache.org >> Subject: RE: Branching/Merging Strategy >> >> > From: leojhartiv [mailto:leo.h...@gmail.com] >> > Sent: Saturday, February 18, 2012 8:36 AM >> > To: users@subversion.apache.org >> > 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-tp33348661p33365655.html Sent from the Subversion Users mailing list archive at Nabble.com.
