[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Log Message Templates vs Server->Client Configuration.

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2005-05-17 19:13:36 CEST

On Tue, 2005-05-17 at 11:02 +0200, Branko ╚ibej wrote:
> You know, I'm totally against adding a server->client transmission
> channel that's useful only for log message templates. Whatever we decide
> to do, even if it's only *used* for log templates in 1.3, must be
> designed so that the same mechanism can be extended for other uses.
> Otherwise we're headed for the proverbial maze of twisty little
> passages, all alike.

I think your attitude falls on the "I want a big hammer to use on all
these vaguely nail-shaped objects" side of the line.

> >Anyway: no server->client configuration transmission mechanism here.

> Eh? What is this if it isn't a server->client configuration transmission
> mechanism? That you want to implement it with a hook doesn't change that. :)

It's a log template mechanism. It outputs a log template, it only
operates when a log template is needed, and it allows programmatic
determination of what the template is. Only by insisting that log
templates be viewed as "configuration" (which is a poor viewpoint when
they can be programmatically determined each time one is constructed)
can you see this as resembling a generic s->c configuration transmission
mechanism.

But if you're going to insist that all server to client transmission be
handled in the same way, I'll point out that we already have a lot of it
handled through properties, particularly svn:ignore. So if we have to
use the same hammer for all vaguely-nail-shaped-objects, we must use
properties for everything.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 17 19:14:48 2005

This is an archived mail posted to the Subversion Dev mailing list.