> -----Original Message----- > From: leojhartiv [mailto:leo.h...@gmail.com] > Sent: Tuesday, February 21, 2012 11:49 AM > To: users@subversion.apache.org > Subject: RE: Branching/Merging Strategy > > > As a follow-up, strategy #2 seems to describe what my team is doing: > http://blogs.collab.net/subversion/2007/11/branching-strat/ > >
Okay, fair enough. On that page, even though it does not explicitly say so, I believe the blue dots represent released versions of software. So it shows release on a "system version" branch and then merge that to a "trunk". The one I described is listed there as "1. The unstable trunk" model. Though certainly the term "unstable" is a relative term. Our main development/integration branch is not unstable. We constantly run builds/tests to ensure it is not unstable. > > 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? > > For branch strategy #1, hot fixes, patches, service packs, whatever are done on the "release" branch or even on a branch from the release branch. Either strategy can work, given correct merging. Be sure you've got someone on the team who understands the svn mechanics of when & how to do all the kinds of merges. -Steve > > > > 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-tp33348661p33366451.html > Sent from the Subversion Users mailing list archive at Nabble.com.
