On Apr 1, 2012 6:00 PM, "Graham Leggett" <[email protected]> wrote: > > On 01 Apr 2012, at 11:29 PM, Greg Stein wrote: > > >> What about svn:mergeinfo? > > > > So? Do I need to run 'svn diff' on every commit to see what happened? > > Isn't that the very definition of svn diff? To tell us what happened?
If you need details that not summarized in the log message. Of course. My point is that svn:mergeinfo is not a replacement for proper branch management and helpful log messages. > > 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? You're exhausted by an email discussion? That somehow, feedback on constructing releases is a poor use of your limited bugfixing time? > > Between you and Jeff and whoever else wants to chime in, formulate a proper *workable* backport strategy. *document* it properly so that it can be found easily at http://apr.apache.org, and I will happily follow whatever you've decided to do. http://subversion.apache.org/docs/community-guide/conventions.html#log-messages http://subversion.apache.org/docs/community-guide/releasing.html#release-branches http://subversion.apache.org/docs/community-guide/releasing.html#porting-changes There's a good section on managing the CHANGES file, but I can see the need for a special policy given the trunk/branch disparity. -g
