On Wed, Jun 12, 2013 at 5:29 PM, Julian Foad <[email protected]> wrote: > Lieven Govaerts wrote: > >> On Wed, Jun 12, 2013 at 2:06 PM, [email protected] <[email protected]> wrote: >>> URL: http://svn.apache.org/r1492168 >>> Log: >>> Implement '--log' option for 'svn mergeinfo --show-revs' >>> subcommand to print revisions log message, author and date. >> >> Thank you! > > This makes sense to me as a feature extension. In any GUI I'd expect to be > able to view the log messages of any revision numbers displayed by such a > command. > > Lieven explained to me how the previous method of piping 'svn mergeinfo' > through 'xargs svn log' is a bit more complex than it would ideally be -- not > least on Windows, of course. > >> The one remark I have on the feature (I didn't review the code), is >> that the revisions are logged oldest-first, whereas the 'svn log' >> output prints from most recent to oldest. >> >> I think we should be consistent here and reorder svn merge info --log >> output most recent first. > > Well... maybe. I have no problem with that as such... but then the default > direction of > > svn mergeinfo --show-revs=... --log > > would be different from the default direction of > > svn mergeinfo --show-revs=... > > So, would we want to consider changing the default direction of the latter? > I think not, because people are probably using it to drive merging-related > scripts and there is no very compelling reason to change it at the expense of > breaking those. > > I guess it's OK for the default to be backwards with the --log option (for > consistency with 'svn log'), and forwards otherwise (for back-compat). > > On the other hand, I think consistency *within* the 'svn mergeinfo' command > should take precedence over consistency across different commands. Just like > for 'svn log --diff', where consistency with 'svn log' should take precedence > of consistency with 'svn diff'.
Now that I have a bit more experience with svn mergeinfo --log from reviewing the revisions from serf trunk that can be backported to serf release branches, I think the most recent first order is the more natural, at least for this use case. > ===================== > > More generally, how many features of "svn log" do we want "svn mergeinfo > --log" to support? I miss --limit, or another easy way to select only those revisions on trunk since the last patch release (of course I can lookup the revision of the last tag, but --limit 50 is easier). Lieven > --diff? > --quiet? > --verbose? > --search? > > Can we think of a way of enabling these kinds of options, that doesn't > involve expanding the 'svn mergeinfo' command to encompass all of the 'svn > log' and 'svn diff' options? Some middle ground between that and leaving it > up to the user to script it? > > - Julian
