Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c
Attached... just in case svn.merge Description: Binary data svn.record Description: Binary data > On Mar 2, 2016, at 2:10 PM, Jim Jagielskiwrote: > > yeah, I use svn.merge and svn.record (for those cases where > I use a actual patch file, but want to record the SVN metadata) > >
Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c
yeah, I use svn.merge and svn.record (for those cases where I use a actual patch file, but want to record the SVN metadata)
Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c
On Wed, Mar 2, 2016 at 5:04 PM, Eric Covenerwrote: > > Dunno if this is always clear to newcomers but some of use a script called > svn.merge which helps with routine merges. > > http://webcache.googleusercontent.com/search?q=cache:WHtgz59cWzoJ:people.apache.org/~jorton/svn.merge+=1=en=clnk=us Oh, it seems you just saved me a lot of time and repetitive work :) > > It's good for the crude but effective gmail archive searches. Thanks a bunch!
Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c
On Wed, Mar 2, 2016 at 10:59 AM, Yann Ylavicwrote: > 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... Dunno if this is always clear to newcomers but some of use a script called svn.merge which helps with routine merges. http://webcache.googleusercontent.com/search?q=cache:WHtgz59cWzoJ:people.apache.org/~jorton/svn.merge+=1=en=clnk=us It's good for the crude but effective gmail archive searches.
Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c
tl;dr I like commit messages :) On Wed, Mar 2, 2016 at 3:31 PM, Stefan Eissingwrote: > 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...
Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c
I will add the revision numbers to the log when merging - no problem. You are correct that things can only work when everyone follows common practise, or - lacking knowledge - learns to do so. -Stefan > Am 02.03.2016 um 16:15 schrieb William A Rowe Jr: > > On Wed, Mar 2, 2016 at 8:31 AM, Stefan Eissing > 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. But I am not trying to change existing > practise here that works. And with pre-supplied 2.4 patches, this > information might not be there - depends how it was created. > > Counter-smart-ass reply; while dealing in email/commit history through > viewvc and similar, the svn:mergeinfo is similarly clear and easily > reviewed. I follow both practices, svn merge for the summary you are > looking at above, combined with a log message that can be followed > by a later reviewer or troubleshooter. > > Please do stick with practice and follow the svn conventions in use here? > Those are always up for discussion but should be discussed and even > more-so agreed upon on the dev list. That includes attribution plus PR > and revision references in the commit log text (and CVE references, but > we will often edit those logs after a security release has been shipped > as not to call attention to the side-effects of a bug fix too quickly). > >
Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c
On Wed, Mar 2, 2016 at 8:31 AM, Stefan Eissingwrote: > 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. But I am not trying to change existing > practise here that works. And with pre-supplied 2.4 patches, this > information might not be there - depends how it was created. > Counter-smart-ass reply; while dealing in email/commit history through viewvc and similar, the svn:mergeinfo is similarly clear and easily reviewed. I follow both practices, svn merge for the summary you are looking at above, combined with a log message that can be followed by a later reviewer or troubleshooter. Please do stick with practice and follow the svn conventions in use here? Those are always up for discussion but should be discussed and even more-so agreed upon on the dev list. That includes attribution plus PR and revision references in the commit log text (and CVE references, but we will often edit those logs after a security release has been shipped as not to call attention to the side-effects of a bug fix too quickly).
Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c
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. But I am not trying to change existing practise here that works. And with pre-supplied 2.4 patches, this information might not be there - depends how it was created. -Stefan > Am 02.03.2016 um 15:05 schrieb Yann Ylavic: > > On Wed, Mar 2, 2016 at 2:10 PM, wrote: >> Author: icing >> Date: Wed Mar 2 13:10:05 2016 >> New Revision: 1733279 >> >> URL: http://svn.apache.org/viewvc?rev=1733279=rev >> Log: >> backport > > We should try to reference the backported (trunk) revisions in the > commit messages. > Otherwise it could be hard later to figure which commit was backported > (or not), and we sometimes need to search by revision number (either > in revision logs, or even gg)...
Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c
On Wed, Mar 2, 2016 at 2:10 PM,wrote: > Author: icing > Date: Wed Mar 2 13:10:05 2016 > New Revision: 1733279 > > URL: http://svn.apache.org/viewvc?rev=1733279=rev > Log: > backport We should try to reference the backported (trunk) revisions in the commit messages. Otherwise it could be hard later to figure which commit was backported (or not), and we sometimes need to search by revision number (either in revision logs, or even gg)...