You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by leojhartiv <le...@gmail.com> on 2012/02/18 17:35:52 UTC
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/trunk " "
http://myrepos/branches/2.0.0 http://myrepos/branches/2.0.0 "
Or in the case of a new maintenance branch:
svn copy " http://myrepos/trunk http://myrepos/trunk " "
http://myrepos/branches/2.0.0 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/2.0.0
http://myrepos/branches/1.1.0 "
" http://myrepos/trunk http://myrepos/trunk "
We then merge trunk into any future releases still pending and resolve any
conflicts:
svn merge " http://myrepos/trunk http://myrepos/trunk " "
http://myrepos/branches/2.0.0 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/trunk " "
http://myrepos/branches/2.1.0 http://myrepos/branches/2.1.0 "
svn copy " http://myrepos/trunk http://myrepos/trunk " "
http://myrepos/branches/3.0.0 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/trunk http://myrepos/branches/2.0.0 "
" http://myrepos/branches/2.1.0 http://myrepos/branches/2.1.0 "
svn copy " http://myrepos/trunk http://myrepos/branches/2.0.0 "
" http://myrepos/branches/3.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!
--
View this message in context: http://old.nabble.com/Branching-Merging-Strategy-tp33348661p33348661.html
Sent from the Subversion Users mailing list archive at Nabble.com.
RE: Branching/Merging Strategy
Posted by "Varnau, Steve (Seaquest R&D)" <st...@hp.com>.
> -----Original Message-----
> From: leojhartiv [mailto:leo.hart@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:JohnM@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.varnau@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.hart@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.
RE: Branching/Merging Strategy
Posted by leojhartiv <le...@gmail.com>.
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:JohnM@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.varnau@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.hart@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.
RE: Branching/Merging Strategy
Posted by Bob Archer <Bo...@amsi.com>.
> 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?
>
We don't use trunk. It is too messy and can cause to many cyclic merges. What we do is create a folder for each release. When we start on a new release we copy the current release to a new folder... so our project looks like this:
Project/
Version1.0.0
Version1.0.1 <-- a copy of Version1
Version1.0.2 <-- a copy of Version1.0.1
Version1.1.0 <-- a copy of Version 1.0.2
Branches/ <-- feature branches go here... copied from whatever version we are going to add the feature too.
Feature1 <-- copied from 1.1.0 a major feature that will span sprints
Tags/ <-- release tags
Version1.0.0_RTM <-- tag of Version1.0.0
Version1.0.0.1_RTM <-- tag of Version 1.0.0 after the .1 fixes have been released.
We only copy at the service pack level or higher which is our third version number. Fixes are also released out of that same folder.
We apply fixes to the lowest release version that we still support and merge that UP version. So, a fix applied to 1.0.2 commited to 1.0.2 and tested there. Once it is approved it is merged up to 1.1.0.
It does happen every now and then that we will fix something in a version and need to backport it. In this case we merge that item DOWN version and then do a record only merge of that merge in the version it was created in so future UP version merges won't see conflicts due to a cyclic merge.
This has worked much better for us than the ALL dev in trunk model. It also have made builds easier because we don't have to constantly change the build settings in trunk... the build settings are modified after we make our copy for the new version and then the cruisecontrol.net config file (which is checked in) is modified after a working copy is created for the new version path on the build server.
BOb
>
> Varnau, Steve (Neoview) wrote:
> >
> >> -----Original Message-----
> >> From: John Maher [mailto:JohnM@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.varnau@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.hart@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.
RE: Branching/Merging Strategy
Posted by leojhartiv <le...@gmail.com>.
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:JohnM@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.varnau@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.hart@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.
RE: Branching/Merging Strategy
Posted by John Maher <Jo...@rotair.com>.
Yes it was helpful. Thanks.
-----Original Message-----
From: Varnau, Steve (Seaquest R&D) [mailto:steve.varnau@hp.com]
Sent: Monday, February 20, 2012 12:40 PM
To: John Maher
Cc: users@subversion.apache.org
Subject: RE: Branching/Merging Strategy
> -----Original Message-----
> From: John Maher [mailto:JohnM@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.varnau@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.hart@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
RE: Branching/Merging Strategy
Posted by "Varnau, Steve (Seaquest R&D)" <st...@hp.com>.
> -----Original Message-----
> From: John Maher [mailto:JohnM@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.varnau@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.hart@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
RE: Branching/Merging Strategy
Posted by "Varnau, Steve (Seaquest R&D)" <st...@hp.com>.
> From: leojhartiv [mailto:leo.hart@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