Greg Hudson <ghudson@MIT.EDU> writes:
> On Wed, 2005-05-18 at 17:48 -0500, C. Michael Pilato wrote:
> > 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).
>
> I don't understand; is this objection to the whole idea of a log message
> template feature, because the user might choose to ignore the template
> when filling out the log message?
Nono. It's simply a request to minimize effort that is very likely to
be undone. I think log message templates are a good thing. I suspect
that the most common uses for log message templates are quite
satisfied by static templates. That's 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 didn't overlook that idea. It came under consideration here:
>
> I like this idea because the hook script can do interesting
> things with the list of modified files.
> [...]
> Any log template mechanism where the server transmits static
> data to the client is inherently limited in this respect,
> because can't have the server telling the client to execute
> code (barring the addition of a sandboxed virtual interpreter to
> the client).
My bad -- I seem to have missed that. Thanks, Greg.
> Substitutable sections allows us to insert the list of modifiable
> files, and perhaps format it in a predefined set of ways, but it
> will always be more limited than letting the server run arbitrary
> code to process it.
Oh, absolutely. No debate there.
> A similar argument holds for deciding which log message to use
> depending on the path being committed. With static data, we could
> have the client decide based on predefined kinds of rules
> (e.g. something like what CVS has, with regexp matches), but it's
> necessarily more powerful to let the server decide any way it wants.
Nor here.
Nobody can reasonably debate the feature flexibility provided by
server-side path crunchin'. The debate (for me) is about flies and
Buicks (feature overkill), and about well apples and sausages go
together (building atop server->client config).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 19 18:27:28 2005