Re: RFC: Log Message Templates via new hook.

kfogel@collab.net wrote:
> John, your scenario assumes that the server admin has *already*
> implemented some sort of per-directory template association. Let's
> remember that they don't have to do that at all. They can just ignore
> all those paths, or do something else with them.

Not exactly. I was looking at the worst-case scenario (complicated multiple log
templates) and seeing how the server hook idea gives us anything special and it
*doesn't* help the most complicated case any more than the simplest case.

There are a number of different use-cases for log templates that I can imagine
(and probably some I can't ;-):

0 - there is no site specific template
1 - there is a single site specific template
10 - there is a specific template for each project
100 - there is a different template for different portions of each project

(numbers not intended to be anything but representatives of real-world complexity).

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.

However, when I was thinking about how to answer your e-mail, I finally figured
out what was really bothering me about the server-hook: it requires maintaining
meta-data about the contents of the repository outside of the repository itself.

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. Rather than
having the template emerge directly from the repository itself, that metadata
must be manually encoded into the hook script, which can lend itself to mistakes
(e.g. after a major reorganization).

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).

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