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