On Sun, Apr 1, 2012 at 17:04, Jeff Trawick <[email protected]> wrote: > On Sun, Apr 1, 2012 at 4:55 PM, Greg Stein <[email protected]> wrote: >> On Sun, Apr 1, 2012 at 11:23, <[email protected]> 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. -g
