You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by David Aldrich <Da...@EMEA.NEC.COM> on 2016/11/14 10:45:25 UTC
How to maintain a release branch?
Hi
I would be grateful for some advice on how to maintain a release branch.
Suppose we create a release branch, finalise the work and make the release. We then maintain fixes for that release on that branch.
Q1. As we apply fixes to the release branch, should we also manually apply those fixes to the trunk (where main development is proceeding)?
Q2. Does there come a point when one should merger the release branch back into the trunk (or does Q1 imply that this is unnecessary because we have manually duplicated the changes in the trunk)?
Q3. If we should merge the release branch back into the trunk, do we merge from trunk to release branch first (I guess not because that would pollute the branch)?
Best regards
David
Re: How to maintain a release branch?
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Nov 14, 2016 at 10:45:25AM +0000, David Aldrich wrote:
> Hi
>
> I would be grateful for some advice on how to maintain a release branch.
>
> Suppose we create a release branch, finalise the work and make the release. We then maintain fixes for that release on that branch.
>
> Q1. As we apply fixes to the release branch, should we also manually apply those fixes to the trunk (where main development is proceeding)?
>
> Q2. Does there come a point when one should merger the release branch back into the trunk (or does Q1 imply that this is unnecessary because we have manually duplicated the changes in the trunk)?
>
> Q3. If we should merge the release branch back into the trunk, do we merge from trunk to release branch first (I guess not because that would pollute the branch)?
>
> Best regards
>
> David
>
Have you taken a look at how the Subversion project iself does this?
The whole process is documented in these sections of the SVN project's
Community Guide:
"Subversion release process"
http://subversion.apache.org/docs/community-guide/releasing.html#release-process
"Creating and maintaining release branches"
http://subversion.apache.org/docs/community-guide/releasing.html#release-branches
It's a bit of a long read, and not all of this will be directly applicable
to any given situation. But perhaps it can serve as a source of inspiration.
Take a close look at how the STATUS file works, and the process around
merging fixes to release branches. Note how our trunk is open for commits
at any time without prior review, while the release branches are not.
Consider how the STATUS file might as well be a ticket database, or a
whiteboard on the wall. Some might prefer merging fixes from release branches
to other branches and trunk, instead of from trunk to release branches.
As long as merges are done by cherry-picking changes between branches,
the direction of the merge really does not matter.
Be careful about using trunk as a "stable" release branch and then also
branching "feature branches" for development off of trunk at the same time.
While it can be done, that approach does not tend to work very well with SVN.
Putting releases on a dedicated release branch usually gives better results.
This is different from how many other version control systems work, but is
consistent with how people used to work with CVS (which SVN is a successor of).
In any case, you'll need to be planning ahead and make sure every developer
involved understands the process.
Regards,
Stefan
Re: How to maintain a release branch?
Posted by Stefan Hett <st...@egosoft.com>.
Hi David,
On 11/14/2016 12:59 PM, David Aldrich wrote:
> Hi Stefan
>
> Thanks for your reply.
>
>> a) you manually apply changes to trunk and the release branch
> One thing I've never been sure of with svn is whether manually applying the same change (i.e. by edits not merges) on branch and trunk is a good idea. Can that result in conflicts when merging later?
Yes it can. But again this depends on the process. If you only apply the
change in a file without really merging it, SVN won't add the marker
flagging that change got merged already. Hence a following merge of that
change (revision) will try to merge the change again. This can result in
a conflict, if the lines close to the change are out of sync between the
release branch and trunk. It won't cause a conflict, if the content of
both files is the same.
Certainly, if you use a proper merge, SVN won't try to merge the changes
again and hence this scenario won't cause a conflict then.
--
Regards,
Stefan Hett
Re: How to maintain a release branch?
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Nov 14, 2016 at 6:59 AM, David Aldrich <Da...@emea.nec.com>
wrote:
> Hi Stefan
>
> Thanks for your reply.
>
> > a) you manually apply changes to trunk and the release branch
>
> One thing I've never been sure of with svn is whether manually applying
> the same change (i.e. by edits not merges) on branch and trunk is a good
> idea. Can that result in conflicts when merging later?
>
Merge tracking does not have a huge impact on the actual merge, it has an
impact on what revisions are merged. So in a release branch, I do not
think it would make a lot of difference either way. The one scenario were
merge tracking might yield fewer comments is if you use it to merge a
revision(s) today and then later on you decide to merge everything (or an
overlapping revision range). Merge tracking will make that followup merge
smart enough to not re-merge the revisions you already merged. So that can
help have fewer conflicts. But that is not a very common or normal
scenario for a release branch.
From a pure documentation/history standpoint, I think it is better if you
make the change on one branch and then merge it to the other. But
technically speaking, merge is kind of just a fancy editor process to make
the same changes to the same files. With the addition that it also creates
some metadata about the merge that can be nice to have for your records
keeping.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
RE: How to maintain a release branch?
Posted by David Aldrich <Da...@EMEA.NEC.COM>.
Hi Stefan
Thanks for your reply.
> a) you manually apply changes to trunk and the release branch
One thing I've never been sure of with svn is whether manually applying the same change (i.e. by edits not merges) on branch and trunk is a good idea. Can that result in conflicts when merging later?
BR
David
> -----Original Message-----
> From: Stefan Hett [mailto:stefan@egosoft.com]
> Sent: 14 November 2016 11:50
> To: users@subversion.apache.org
> Subject: Re: How to maintain a release branch?
>
> Hi David,
> On 11/14/2016 11:45 AM, David Aldrich wrote:
> > Hi
> >
> > I would be grateful for some advice on how to maintain a release branch.
> >
> > Suppose we create a release branch, finalise the work and make the release.
> We then maintain fixes for that release on that branch.
> >
> > Q1. As we apply fixes to the release branch, should we also manually apply
> those fixes to the trunk (where main development is proceeding)?
> That depends on what's best for your process... In principle three common
> approaches work:
> a) you manually apply changes to trunk and the release branch
> b) you apply the fix to trunk and merge (cherry-pick) the related revision to the
> release branch
> c) you apply the fix to the release branch and backport it (via merge) to trunk
> (which can also be done in chunks at a given point
>
> We normally use approach b and have set up batch file which runs once per
> day to merge all flagged revisions (via a tag in the log message) which were
> committed to trunk to the release branch.
>
> > Q2. Does there come a point when one should merger the release branch
> back into the trunk (or does Q1 imply that this is unnecessary because we have
> manually duplicated the changes in the trunk)?
> That heavily depends on your requirements. In general I don't see the need for
> that. One case where it would make sense would be if you also make changes
> to the release branch which you want to backported to trunk.
>
> > Q3. If we should merge the release branch back into the trunk, do we merge
> from trunk to release branch first (I guess not because that would pollute the
> branch)?
> Only if you want all the changes in trunk to get merged into the release
> branch. Based on your description, I take it that's not what you want.
> Hence, the answer is no.
>
> --
> Regards,
> Stefan Hett
>
>
>
> Click
> https://www.mailcontrol.com/sr/Vj6aNZznnVPGX2PQPOmvUjekYHk5lulQevXi
> WVMqtR+Dmom+3B8m+QDuj+v!60mN2Cfu6uLF7dONc!rJiVGaJg== to report
> this email as spam.
Re: How to maintain a release branch?
Posted by Stefan Hett <st...@egosoft.com>.
Hi David,
On 11/14/2016 11:45 AM, David Aldrich wrote:
> Hi
>
> I would be grateful for some advice on how to maintain a release branch.
>
> Suppose we create a release branch, finalise the work and make the release. We then maintain fixes for that release on that branch.
>
> Q1. As we apply fixes to the release branch, should we also manually apply those fixes to the trunk (where main development is proceeding)?
That depends on what's best for your process... In principle three
common approaches work:
a) you manually apply changes to trunk and the release branch
b) you apply the fix to trunk and merge (cherry-pick) the related
revision to the release branch
c) you apply the fix to the release branch and backport it (via merge)
to trunk (which can also be done in chunks at a given point
We normally use approach b and have set up batch file which runs once
per day to merge all flagged revisions (via a tag in the log message)
which were committed to trunk to the release branch.
> Q2. Does there come a point when one should merger the release branch back into the trunk (or does Q1 imply that this is unnecessary because we have manually duplicated the changes in the trunk)?
That heavily depends on your requirements. In general I don't see the
need for that. One case where it would make sense would be if you also
make changes to the release branch which you want to backported to trunk.
> Q3. If we should merge the release branch back into the trunk, do we merge from trunk to release branch first (I guess not because that would pollute the branch)?
Only if you want all the changes in trunk to get merged into the release
branch. Based on your description, I take it that's not what you want.
Hence, the answer is no.
--
Regards,
Stefan Hett
RE: How to maintain a release branch?
Posted by Scott Aron Bloom <sc...@towel42.com>.
For my company, we do the following.
For externals, use the pegging format
We copy every release to our releases branch
https://XXX/svn/releases/major.minor.svnrev
For released bugs, that are to be fixed via patch release, the policy is to fix it on the branch and then merge it to trunk. When this is done, merging is pretty easy
However, this sometimes gets forgotten, and the fix is done on top of trunk, and then merge the specific revision onto the release. This flow tends to cause conflicts overall.
Where this breaks down, is when some form of code change has occurred on trunk, that forces the fix to be done differently between the release and trunk.. This causes problems, and the question has to be asked, how critical is the bug for the patch.
For Q2,the ONLY time code is NOT merged from the release to trunk, is when the issue has been fixed in a different manner
Q3) we don't merge from tot "blindly" only specific and targeted revisions.. otherwise we just create a new release branch from the current tot
Scott
-----Original Message-----
From: David Aldrich [mailto:David.Aldrich@EMEA.NEC.COM]
Sent: Monday, November 14, 2016 2:45 AM
To: 'users@subversion.apache.org' (users@subversion.apache.org) <us...@subversion.apache.org>
Subject: How to maintain a release branch?
Hi
I would be grateful for some advice on how to maintain a release branch.
Suppose we create a release branch, finalise the work and make the release. We then maintain fixes for that release on that branch.
Q1. As we apply fixes to the release branch, should we also manually apply those fixes to the trunk (where main development is proceeding)?
Q2. Does there come a point when one should merger the release branch back into the trunk (or does Q1 imply that this is unnecessary because we have manually duplicated the changes in the trunk)?
Q3. If we should merge the release branch back into the trunk, do we merge from trunk to release branch first (I guess not because that would pollute the branch)?
Best regards
David