On 18 May 2005 16:49:32 -0500, kfogel@collab.net <kfogel@collab.net> wrote:
> That's "RFC" as in "Request For Consensus" :-).
>
> Discussion seems to have died down, and that may be because people
> mostly agree on the way to go now. So, I'd like to get consensus on
> this proposal:
>
> A new RA method, svn_ra_get_log_message_template(), that takes a
> list of paths and returns the log message template. On the server
> side, this is implemented by invoking a new 'log-message-template'
> hook, which takes the author as an an argument and a
> newline-separated list of (UTF8) paths on stdin. Whatever the hook
> prints to stdout is the log message template. If it prints
> nothing, or there is no hook, then there is no log message template
> and the client behaves as it does today.
>
> The RA method is invoked only when interactive $EDITOR is used to
> write a log message.
>
> (Whether the RA method takes a static list of paths, or receives
> them via repeated callback invocations, is something we will have
> to work out; but this does not affect the overall proposal.)
>
> The server would know the author because of the RA layer's
> authentication; the client would not have to pass the author name
> to svn_ra_get_log_message_template().
>
> We will ship with a default 'log-message-template.tmpl' file that
> just ignores the paths and prints a standard-looking template to
> stdout. But the .tmpl file would document the hook's calling
> discipline fully, of course.
>
> Obviously, there are some details to be worked out here, but this is
> well-specified enough to ask for consensus on the general approach.
I really like the idea, but want to summarize the underlying
assumptions anyway. You seem to be assuming that:
* A template will only be requested when no log message has been
provided for the commit (ie when we need to pop up an editor)
* The per-directory approach won't work, since some repositories hold
more than one project (example: ASF)
* The extra network turn-around is something to be discussed when it
turns out to be a real problem
* The per-directory template with substituteable values is not an
option, because the loss in flexibility can't be accepted and the
solution to that (implementing a client-side interpreter) is not an
option
Am I correct so far? If I am, I have a few questions:
If these are the underlying assumptions, then why won't the
per-directory static template work? If every project has its own
template, I'd expect it to work, since people will have checked out a
working copy per project (and thus have one template per commit). The
fact that CVS needs the directory matching algorithm could be because
a CVS module can be a separate project - needing its own template.
Also, we seem to (mostly) forget that a network turnaround may not
always be a http or svn connection: setting up svn+ssh connections -
if not reused - may be a major annoyance to users when they don't have
ssh-agent set up. Although this is probably one of the implementation
details you were talking about, it's an important one IMO.
If we can assume one template for a complete project, then wouldn't
substituting values into log message templates - without a server hook
script - be a *big* improvement over what CVS supplies?
Would having the possibility to generate a log template offline be
considered a benefit? (Without taking into account which limitations
it might imply.)
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 19 11:46:31 2005