On Sun, Apr 1, 2012 at 5:13 PM, Greg Stein <gst...@gmail.com> wrote: > On Sun, Apr 1, 2012 at 17:04, Jeff Trawick <traw...@gmail.com> wrote: >> On Sun, Apr 1, 2012 at 4:55 PM, Greg Stein <gst...@gmail.com> wrote: >>> On Sun, Apr 1, 2012 at 11:23, <minf...@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
