[PROPOSAL] enforce log messages as series of lines

This proposal results from the recent thread around Olleg Samoylov's
patch to the command line client:

http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=433505

(This proposal is not quite the same as Olleg's patch, however.)

Whatever we decide here, I'd like to record it in issue #1870, so we
can remember and not go around this circle every six months :-).

THE PROBLEM:
------------

Currently 'svn log' output is needlessly inconsistent about whether or
not there is a blank line before the separator. For example, see
r18480 and r18479 in Subversion's repository, compare them with other
nearby revisions.

Also, some users get confused by the fact that log messages committed
with -m versus -F versus $EDITOR can have different results (in fact,
users could achieve identicalness, but the means of doing so are
fairly unintuitive for most people).

THE SPACING CAVEAT:
-------------------

Some also find the current waste of vertical space annoying: since
most log messages already end with a newline, adding an unconditional
extra newline (as we do today) causes a blank line before the
separator in most cases. However, other people find the logs much
easier to read with that blank line. Thus it might be that, after
making all the changes described below, the command-line client should
*still* print an extra blank line.

THE HOOK ALTERNATIVE:
---------------------

(We're just about to get to the proposal, really, just one more
thing...)

Most of what people want can be achieved with hooks. Just have a hook
that enforces whatever log message conventions you want, and then fix
up your old messages to conform to the new format. The hook program
can even be written to run in a standalone mode to make it easy for
the admin to fix up all the old revisions. Of course, you still have
to install the hook, and maybe it's better for Subversion to do what
most people expect by default. However, keep the hook alternative in
mind.

THE PROPOSAL:
-------------

Subversion should enforce that a log message is a series of lines of
UTF8 text. A "line" is a series of zero or more non-newline
characters (qualified by whatever other restrictions we currently put
on log messages), followed by a single newline. Thus, every log
message would end with a single newline.

(Note that subversion already enforces that log messages are stored as
UTF8, although of course they may be printed in a different encoding
in the client locale)

On the server side, we would silently enforce the new format:

   1. On arrival, log messages that end with something other than a
      newline would have a single newline appended. (For convenience,
      log messages that end with multiple newlines could have that
      reduced to a single newline, but IMHO that is an optional part
      of this proposal. Similar statement applies to log messages
      that end with a mixture of other whitespace chars -- e.g.,
      SPACE, TAB, CR -- and newlines.)

   2. On retrieval, log messages would also be checked & similarly
      reformatted. This takes care of revisions that were committed
      before the server was upgraded. (We may or may not replace the
      old svn:log prop with the new, I don't think it matters much.)

In the command-line client, we would:

   a) When printing out a log message, no longer unconditionally print
      an extra newline in 'svn log' output to ensure that the log
      message body doesn't scrunch up against the following separator
      line. Instead, as a compatibility measure, check to see if the
      message already ends with a single newline; if it does, print
      nothing extra, otherwise, print a single extra newline and
      adjust the header's line count appropriately. (*** But see
      "Spacing" below ***).

   b) When taking a log message as input, enforce the same things the
      newer servers would enforce (thus if you commit with a new
      client to an old server, someone else running 'svn log' against
      that server with an old client will still get the new hotness.)

After this, the only way to run into the old behavior would be to do
'svn log' with an old client, against an old server, retrieving the
log message for a revision that was also committed with an old client.

FWIW, I'm -1 on applying Olleg's patch by itself. I think we should
either enforce a log message convention throughout the entire system,
or stick with the current behavior (which still leaves open the
possibility of a hook solution).

Thoughts?

-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org