[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: Branko Čibej <brane_at_xbc.nu>
Date: 2005-05-17 21:36:29 CEST

Greg Hudson wrote:

>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.
You're overreacting, as usual.

According to Karl's proposal, we'd have a special RA function to get the
log template... then later on, we'd find something else for the client
to pull from the server, and add a second RA function... and a third...
That's nuts; even more so because it costs almost nothing to have the
function take an additional parameter that identifies the data to be sent.

Properties are fine for situations where you don't need or want an extra
network turnaround, but not for what's being discussed here.

Just for the record. IMHO we don't need it for log templates, either. It
may be sexy to have them generated based on the set of paths to be
committed, but that /is/ overkill IMNSHO. 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.

-- Brane

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 17 21:38:04 2005

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.