On Wed, Jun 12, 2013 at 5:29 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Lieven Govaerts wrote:
>> On Wed, Jun 12, 2013 at 2:06 PM, ivan_at_apache.org <ivan_at_apache.org> wrote:
>>> URL: http://svn.apache.org/r1492168
>>> 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).
> 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
Received on 2013-09-02 21:53:46 CEST