kfogel wrote:
> In http://subversion.tigris.org/issues/show_bug.cgi?id=2367 I
> suggested the following as a 2.0 change:
>
>> Currently 'svn log' output shows the number of lines in the log message:
>>
>> r1729 | jrandom | 2005-07-31 21:12:50 -0500 (Sun, 31 Jul 2005) | 4
>> lines
>>
>> The idea was to make log messages unambiguously delimited. Someone
>> could even write the default log message separator into their log
>> message and we could still parse 'svn log' output reliably.
>>
>> In practice, no one ever seems to put the log message separator (a
>> line of 72 dashes) into their log messages. Maybe there are cases
>> in the wild I'm unaware of. Meanwhile, people sometimes
>> misinterpret the "N lines" as meaning "N lines were changed in this
>> commit". Oops. If we got rid of that field, we'd have room for
>> other information -- longer usernames, if nothing else. Or we could
>> say "N files" instead, a nice summary of the approximate size of the
>> commit. I dunno, let your imagination run wild.
>>
>> We could add a restriction to the repository API that a log message
>> may not contain the separator line. This would be a special favor
>> to one particular client's output format, which in theory is not
>> something we like to do, but it might make practical sense in this
>> case.
>
> Max Bowsher responded:
>
>> Has there been list discussion on this?
>> If so, please link to it. If not, we need to have some.
>>
>> I dislike this idea - it seems like a step backwards.
>
> There has been no list discussion, until now.
>
> Max, can you elaborate on "seems like a step backwards"? That's
> basically just saying "I don't like this idea because it's bad." :-)
>
> I'm happy to close the 2.0 issue if we don't have consensus that the
> "N lines" field was a mistake. Above, I've laid out the arguments for
> why I think it was a mistake. Do you think it's useful enough to
> outweigh its problems?
>
> Also, which part of the idea don't you like: getting rid of the field,
> adding the server-side separator prohibition, or both?
OK, elaboration:
The field's presence is to allow us to improve over CVS, to make log
messages reliably parsable. It would be a step backwards to reintroduce that
bug.
I agree that including separators in log messages is rare, but there's at
least one rather valid use-case: including all relevant logs for the
revisions of a merge in the merge commit.
Disallowing separators in messages seems like an unpleasantly inelegant
thing to do, and creates an awkward corner case when it comes to svn 1.x ->
2.x migration. Also, I'd hate to have to explain the reasoning to someone
using a GUI client.
Regarding the user confusion issue - I think the proper way to fix that is
to explain the lines field in the svnbook.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 21 17:56:01 2005