apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: svn commit: r1308135 - in /apr/apr-util/branches/1.4.x: ./ CHANGES crypto/apr_crypto.c
Date Sun, 01 Apr 2012 21:13:17 GMT
On Sun, Apr 1, 2012 at 17:04, Jeff Trawick <trawick@gmail.com> wrote:
> On Sun, Apr 1, 2012 at 4:55 PM, Greg Stein <gstein@gmail.com> wrote:
>> On Sun, Apr 1, 2012 at 11:23,  <minfrin@apache.org> wrote:
>>> Author: minfrin
>>> Date: Sun Apr  1 15:23:45 2012
>>> New Revision: 1308135
>>> URL: http://svn.apache.org/viewvc?rev=1308135&view=rev
>>> Log:
>>> Backport:
>>> apr_crypto: Ensure the *driver variable is initialised when a statically
>>> compiled library is initialised for the first time.
>>> Modified:
>>>    apr/apr-util/branches/1.4.x/   (props changed)
>>>    apr/apr-util/branches/1.4.x/CHANGES
>>>    apr/apr-util/branches/1.4.x/crypto/apr_crypto.c
>>> Propchange: apr/apr-util/branches/1.4.x/
>>> ------------------------------------------------------------------------------
>>>  Merged /apr/apr/trunk:r1308131
>> -131 has no edit to CHANGES.
>> When performing backports, you should commit *just* the backport. If
>> you want to make other changes, then keep them in a separate commit.
>> Combining changes like this is poor branch policy. It means that we
>> can no longer trust that a backport is *JUST* the backport. We have to
>> investigate to determine whether other changes were made in the
>> commit.
> That adds an extra step to looking at the code changes for a CHANGES
> entry, if indeed the merger/backporter remembered to list the code
> change in the CHANGES commit.  (Otherwise it is more painful.)

I'm not sure that I follow that statement.

My point is: if you do a backport of a commit, then do *just* the
backport. Throwing other work into that commit leads to insanity.

> I guess you mean that the "trust" part comes not from backports in
> general but only from a a "touchless" merge.  Generally a "backport"
> may require minor changes to reflect other differences in the branch.

For that kind of problem, in Subversion, we create a
branch-of-the-branch then backport the revision, then make the
necessary edits to make the backport conform to the branch. Thus, when
we touch branches/1.N.x, we are doing a simple backport merge. Again:
no other changes in that revision beyond JUST the backport.

So yes: I'm saying touchless merges are the proper way to manage branches.

These two backports today were reckless. Both of them were not
"touchless" to use your term. And worse: that fact was not documented
in the log message. "Backport" is all it said. Not what revision was
backported. Not that other changes were made beyond that
(unidentified) revision.

I can maybe understand a policy that says CHANGES should be edited
directly on the branch (since, at this point, trunk CHANGES and branch
CHANGES are completel dissimilar). But those edits should not be part
of backport merges.


View raw message