On May 18, 2005, at 5:48 PM, C. Michael Pilato wrote:
> 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).
It was my understanding that the roundtrip would only happen when
'svn commit' is run without passing a log message *at all*.
> 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 think that that idea suffers from the same problem that static log
templates suffer: All of the logic for filling out the template (and
deciding what to do in the case of multiple directories with
conflicting templates) must reside in the client.
The advantage of using the hook is that it puts the log message
template control into the hands of the system administrator (and
whatever programming language she's comfortable with).
> 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.
I really do think that the two are apples and sausages, but I'd be
glad to be proven wrong.
> 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.
In that case, let's step back from implementation issues and lay out
some use cases for both log message templates and server-side
configuration options. Once we gather those, then we can start to
develop some concrete requirements before we all (especially myself)
go leaping for the implementation.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu May 19 04:26:33 2005