apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@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:04:52 GMT
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 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.

Mime
View raw message