On Apr 1, 2012 6:00 PM, "Graham Leggett" <minfrin@sharp.fm> 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