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). 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.
>
>
I agree 100% with Mike, couldn't have said it better (and /could/ have
said it a lot worse, but you know me... :)
The feeling I got from this discussion is that it's not really a
discussion at all:
* No-one answered the question whether log-message templates were
really the top priority, compared to, e.g., server-side autoprops.
* The overlap between log templates and server-side config was
mentioned, then completely ignored as irrelevant.
* An awsomely sexy implementation was proposed to dynamically
generate templates (and it can't possibly be reused for
server-side configuration, but this fact was ignored as per
above), but no-one even showed a pressing need for the sort of
flexibility being offered. It's boiled down to a case of "let's do
it because we can."
I also find it *very* disturbing that no-one even analysed how log
tempaltes could be used. The implicit assumption is, "have SVN provide a
tempalte for a commit log message". Based on this very general
requirement, we have on the table a proposal doesn't address the case
where you'd want to generate the template and write the log _before_
running "svn commit". Which, at least for me, is the natural order of
things.
In short, what we're doing is exactly how new features should *not* be
designed. Which is a bit disappointing, because we certainly know that
we /can/ do it right -- the way we arrived at the locking design is a
case in point.
So let's please take a step back.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 19 07:06:35 2005