On 02 Apr 2012, at 2:35 AM, Greg Stein wrote: > My point is that svn:mergeinfo is not a replacement for proper branch > management and helpful log messages. > We're not talking about proper branch management and helpful log messages, both of which are a given. Instead we're talking about duplicating the revision recorded within svn:mergeinfo inside the log message. I was under the impression this duplication wasn't necessary, and that someone needing to know the revision number could simply look it up. I agree that the duplication does make people's lives easier, so am happy to do it. > > > > Personally, I'm am utterly exhausted by constantly being told by this > > person and then that person that some or other completely undocumented > > pattern isn't being followed. All I want to do is fix some bugs, get a > > release out the door, and help some long suffering Windows folks who are > > having problems with static builds. > > Oh, cry me a river. Proper branch management produces repeatable, solid > releases for this users. > > You're "exhausted" by two commit reviews?! Seriously? > No Greg, I am exhausted by constantly being told by this person and then that person that some or other completely undocumented pattern isn't being followed. I thought I made that clear.
This project has come to an agreement in the past over how CHANGES files are to be handled. If you disagree with the way this project has decided to handle CHANGES files, then start a new thread and reboot that discussion. Do not sweep in and accuse me of making reckless backports because I followed the APR project's way of backporting instead of subversion's way of backporting. To be most specific: http://subversion.apache.org/docs/community-guide/releasing.html#the-changes-file "Remember that CHANGES should always be edited on trunk and then merged over to the release branch(es) when necessary. It is very important that all changes of all releases be documented in the CHANGES file on trunk, both for future reference and so that future release branches contain the sum of all previous change logs." While I agree with the above, the rest of the APR project does not. Regards, Graham --
smime.p7s
Description: S/MIME cryptographic signature
