I've been sitting on the sidelines, mostly just to see where the list
took this without my interference. I must say, though, that I (like
Brane) am not thrilled about the idea of essentially asking the
server, for each commit, to run a hook-script to conjure up a bit of
text which itself isn't even necessarily going to be "used" (as in,
outlive the final edits of the commit message). And I'm a little
disappointed that my idea for having the server simply dictate a
static template which contains substitable regions was mostly
overlooked (by all but Brane, it seemed, though that's my fault for
not expressing the idea as more than a top-of-the-head thought).
I appreciate that we have an opportunity here to excel beyond the
limitations of CVS's log message template feature, and I also
appreciate the urge to at least improve over CVS's *implementation* of
that feature, if not the provided functionality. But I can't help but
wonder if the proposal as it sits isn't overkill, and am not so quick
to decide that this feature can't be cheap(ish) fallout of a generic
server->client configuration dictation system. Such system, of
course, does itself not exist, and so is reasonably suspect as
suitable for the support of log message templates. But I think we'd
do well to consider the requirements of both systems, examine their
overlaps, and determine if we have a reasonably common bit of design
work that can be leveraged to maximize simplicity -- perhaps at the
cost of "bonus" functionality -- but without compromising the
essentials of either system.
kfogel@collab.net writes:
> 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.
>
> Objections?
>
> The strongest objections so far came from Brane, I believe, and have
> been responded to on-list, so I won't repeat the details here. Brane,
> I'm certainly not demanding that you give consensus against your
> wishes. However, I think it's better not to pull out the "veto" card
> in your second message :-)...
>
> > Besides, suddenly you'd have an extra trip over the network
> > regardless of whether you use log templates or not, and I'm very
> > close to vetoing the proposal for that reason alone.
>
> Please, let's reserve talk of vetos for after technical discussion has
> failed to lead to a resolution. I realize that formally it doesn't
> matter when one starts mentioning vetos; however, it raises the stakes
> prematurely and can have a polarizing effect on the conversation
> (although I think it didn't in this case, fortunately).
>
> Again, that's a comment about style, not substance. Feel free to
> withold consensus now, and we'll continue discussing if so.
>
> -Karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 19 00:50:34 2005