Vincent Lefevre <firstname.lastname@example.org> writes:
> I disagree with you. Otherwise svn should be modified so that
> "svn ci -m '...'" and "svn ci" with the log message entered in an
> editor should behave in a consistent manner, taking into account
> that the string after the -m doesn't normally contain a newline,
> and in an editor, the user can't remove the newline before the
> line "--This line, and those below, will be ignored--".
The user could easily remove that newline -- I've done it before.
What the user should not do is remove that newline while neglecting to
--This line, and those below, will be ignored--
and everything below it (unless the user wants a very bad-looking log
message, of course).
> The user mustn't be forced to use a hook to avoid an inconsistency
> that svn introduced.
The question of whether svn introduced this inconsistency is a topic
of some dispute, as you may have noticed :-). One could also do
$ svn ci -m "this is a log message ending in a newline
That works, it's just highly unusual for anyone to actually do it.
Summary: in all three methods of passing a log message, there is a way
for the user to control whether or not that message ends with a
newline. The fact that most users don't take advantage of these
methods is perhaps due to certain interface choices on SVN's part, but
the control is certainly there for those who know how to use it.
Therefore to say that SVN did or didn't introduce the inconsistency is
oversimplifying. The inconsistency is a cooperative venture between
SVN and the user -- either of the two parties could take steps to make
the inconsistency go away, and right now we're discussing whether SVN
should be the one to do it. (In the end I think not, since the hook
solution is available, but I certainly see the arguments for the other
side, having just made them myself :-) ).
I think I may drop out of this thread now, unless something genuinely
new is said. (Not a statement about your post, by the way, more about
the entire thread, which I think has covered all the ground there is
to cover here.)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Mar 2 04:39:42 2006