John Peacock wrote:
<SNIP> various scenarios for
>
> The server hook provides exactly the same assistance to site admins for
> each of those scenarios, which is to say, none. The site admin is
> completely free to implement as baroque or simple a hook as they desire,
> but we don't really do anything to facilitate that.
I'm assuming subversion would be distributed with sample scripts that
implement some basic resolution schemes. This would be equivalent to
having the same resolution capability built into the client, but with
greater scope for the admin to tweak/replace the policy if they wish to.
In my mind, the less functionality is embedded in the client the better.
It makes it harder to extend; any expanded functionality would require
all clients on the project to upgrade at the same time. Also, this is
open source and a project can change the server to suit themselves and
this is easier and safer than distributing project-specific customised
clients.
> Let me preface this by saying I know it is possible to version the hooks
> folder; that's not what I am talking about. What I am talking about is
> specifically that, in the more complicated scenarios above, the paths to
> which certain log-templates apply must be hard-coded in the hook script
> itself.
I don't buy that. Why shouldn't the hook script look into the
repository to grab the metadata it uses for log templates? It's
perfectly possible to only implement logic in the hook, and for it to
retrieve path specific parts from any other SCM component not limited to
the repos.
> I think that it is far too early to abandon inherited properties as "too
> hard" since it permits a number of valuable emergent behaviors, not only
> for log templates but for many of the other "server-resident" config
> features which people have been longing for. I just don't think we
> should close off discussion of a more general solution in favor of a
> simple solution for log-templates (which may or may not be the first
> order of business for 1.3 in any case).
Greg made an argument comparing inherited props to symlinks which
totally sold me (though maybe not in the way he intended). Despite
their occasional weirdness I can't imagine *nix filesystems without
symlinks; they're far to useful. I don't think subversion should punt
on this idea.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 20 12:49:13 2005