Greg Stein wrote:
> On Tue, May 17, 2005 at 11:02:17AM +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.
>
>
> Agreed.
I'm torn because Karl/GHudson's idea for log message hooks is so compelling, yet
I also agree with Branko/GStein. As long as any generic s->c mechanism can
support server-side hooks, it will meet both requirements.
If there was a generic svn_client_get_server_config() call which took as a
parameter a key, then the server could compare the key vs. a configurable list
of actions and return the appropriate thing. We /could/ simply make it a key =>
hook hash, and the site admin would have to create an appropriate hook script,
whether we were talking about log templates or autoprops.
> Attach "provisional" properties to files when they are added. Those props
> can come from a dirprop, a per-repos config, or whatever. At commit time,
> if those autoprops have changed on the server, then just bail out of the
> commit with an "out of date" messages. The user does an "svn up" and the
> provisional props get updated to a more recent copy.
I still think that this particular itch can be scratched with inherited
properties (the file inherits any directory properties and the server propagates
properties to the directory upon checkout/update). In particular, I agree with
Greg [Stein] that this doesn't need to be a "polled" during commit; these values
should be stored somehow in the WC files since they wouldn't benefit from a
server-side hook.
It seems to me that there are two broad classes of server config information
which would justify slightly different handling:
1) in-band - config information which depends on which files are present (the
very cool autoformatted log message templates that GHudson dreamed up fall into
this camp); these really need to be a network access during specific points in
the workflow. These config values will always be very context sensitive and
would probably be different for each and every commit.
2) out-of-band - config information which is not dependent the immediate commit.
NOTE I am not saying these values may not depend on which file is being
committed, but rather that they are independent changes to repository and may
apply to many files. Inherited properties (whether dirprops or whaever) fall
into this camp. These should really be a versioned object in the repository and
stored locally in the WC files.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 17 12:59:10 2005