tl;dr I like commit messages :) On Wed, Mar 2, 2016 at 3:31 PM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > I can do that. However - smartass mode on - if one uses the actual > "svn merge -c NNN,NNN", subversion will track that and > > svn mergeinfo --show-revs merged ^/httpd/httpd/trunk . > > in a 2.4.x checkout will show it.
The command above is nice but does not show the 2.4.x revision the trunk one I'm looking for is merged into. Eg., for this current merge, the relevant output is: ------------------------------------------------------------------------ r1732252 | jailletc36 | 2016-02-25 07:51:13 +0100 (Thu, 25 Feb 2016) | 1 line Save a few bytes in conf pool when parsing 'DefaultRuntimeDir' directive. ------------------------------------------------------------------------ r1732353 | jailletc36 | 2016-02-25 20:49:21 +0100 (Thu, 25 Feb 2016) | 1 line Save a few bytes in conf pool when parsing 'DocumentRoot' directive on some OS. ------------------------------------------------------------------------ r1732369 | jailletc36 | 2016-02-25 22:00:46 +0100 (Thu, 25 Feb 2016) | 1 line Save a few bytes in conf pool when parsing 'Mutex' directive on some OS. ------------------------------------------------------------------------ but I can't find any r1733279 there, and had to look at the original STATUS' change: - *) Save a few bytes in conf pool when parsing some directives - Trunk patch: - http://svn.apache.org/r1732252 - http://svn.apache.org/r1732353 - http://svn.apache.org/r1732369 - 2.4.x patch: - Trunk version of patch works - +1: jailletc36, ylavic, icing to figure out. I often have to search for a particular commit revision, mainly in my mailbox (cvs@), to find out what's related, and for this the commit message helps a lot ;) But I agree that I may not be svn expert enough to find the right command by myself... The online viewvc's "Revision Log" does not show the svn properties too, useful tool when you don't have you working copy (or svn) at hand. > But I am not trying to change existing > practise here that works. Honestly I didn't really know it was a required practice (is it?), just always seen it in merge messages and found it useful, so just proposed... > And with pre-supplied 2.4 patches, this > information might not be there - depends how it was created. Right, it should/must? be in STATUS "Trunk patch(es):" though, if referring to a real trunk commit at least (this helps finding and commenting the original commit on review too). No strict opinion on all that though, my personal use of commit messages may be abusive, and if the information I need is missing, well I'll find it some other way... Regards, Yann. PS: I don't like too much top posting too :p There seems to be two "real" schools here, so I adapt...
