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:29:31 GMT
On Sun, Apr 1, 2012 at 5:13 PM, Greg Stein <gstein@gmail.com> wrote:
> 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 agree that throwing in unrelated modifications leads to insanity.
(But our definition of unrelated probably differs; fixing CHANGES in
the commit has not led to insanity so far and has avoided the
potential that the subsequent CHANGES commit didn't reference the code
change.)

>> 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.

Then see what kind of buy-in you get for that in a new thread.

> 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 agree that a log message is busted if it doesn't mention the trunk
revision(s) for the code.  (I don't know how the mergeinfo shows up
when looking at the revisions later.)

> 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.

shrug

Mime
View raw message