[Karl Fogel]
> 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
> also remove
>
> --This line, and those below, will be ignored--
>
> and everything below it (unless the user wants a very bad-looking log
> message, of course).
As an amusing side note, I often remove those lines out of sheer
paranoia. A few weeks ago, I started a commit, but while typing the
log message, realised that I had to make another change before
committing, so I saved the message and aborted. I later committed with
-F, from a different shell that happened to have a different locale.
svn didn't recognise the separator line because it was in the wrong
language, so it used the whole file.
(I blame only myself - but it *was* amusing.)
> > 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
> "
It has already been noted that tcsh can't do this - I'll add that AFAIK
cmd.exe can't either. I don't care very much about either of those,
but there you are.
Just as there are broken shells that don't (easily) allow newlines in
arguments, so there are broken editors that don't allow saving a file
without a newline at the end. pico, for example. I could've sworn
some version of vi wouldn't let me do that either, but I could be
imagining that, since vi is for more sophisticated people.
I would have thrown my support behind the proposal to enforce newlines
in the server, but it seems that's settled now in favor of
log-police.py. Thanks for that script, which I'll install locally and
will probably ship alongside other example hook scripts in Debian's
1.3.x.
Peter
Received on Sun Mar 5 21:34:23 2006