[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: <kfogel_at_collab.net>
Date: 2005-05-18 00:32:51 CEST

Greg Hudson <ghudson@MIT.EDU> writes:
> But log templates require a specific kind of input (the directories to
> be committed) which makes no sense for other kinds of server-to-client
> configuration under discussion.

Wait, though. I think we may be on to something:

If a path list doesn't make sense for other kinds of server-to-client
configurations, then the client need not send it. As long as the
client knows not to send it, and the server knows not to expect it,
everything's fine.

In other words -- trying to think big here -- generalize the proposal:

Have a generic repos hook called 'inquiry'. It can read its
parameters (the first parameter is always a subcommand) and read
stdin, and depending on the subcommand it may or may not write to
stdout. We define calling disciplines for various subcommands: what
further parameters they take, what if anything to expect on stdin, and
what if anything they can write to stdout.

The first subcommand we define is 'log-message-template'. It
(perhaps) takes one optional additional parameter, the author, and it
expects a newline-separated list of paths on stdin. Anything it
writes to stdout gets sent back to the client as the log message
template. If it writes nothing, the client gets no template and
behaves as it does today. We ship with a default ("suggested serving
size") implementation of this subcommand, but anyone is free to
implement their own inquiry hook of course.

We can easily define further subcommands and their I/O disciplines,
for other server->client configuration needs.

And, the best part:

We make sure that from the first release of this feature, all RA
layers have a way for the client to send multiple inquiries & their
parameters in one request, and a way for the server to reply with all
the answers in one response. That way we can add new features later
without adding more network turnarounds.

Fitz: am I giving it to you fast enough?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 18 01:11:21 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.