> -----Original Message-----
> From: leojhartiv [mailto:leo.hart_at_gmail.com]
> Sent: Tuesday, February 21, 2012 11:49 AM
> To: users_at_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:JohnM_at_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_at_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.varnau_at_hp.com]
> >>> Sent: Sunday, February 19, 2012 1:34 PM
> >>> To: leojhartiv; users_at_subversion.apache.org
> >>> Subject: RE: Branching/Merging Strategy
> >>>
> >>> > From: leojhartiv [mailto:leo.hart_at_gmail.com]
> >>> > Sent: Saturday, February 18, 2012 8:36 AM
> >>> > To: users_at_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.
Received on 2012-02-21 23:30:47 CET