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
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?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Jul 20 18:59:24 2005