Re: RFC: Log Message Templates via new hook.

kfogel@collab.net wrote:
> As for whether the freedom is actually worth anything, my reply to
> Mike Pilato earlier was partially a justification:
>
> > Imagine a system whereby, if one makes a single commit across
> > multiple projects within a big ASF-style repository, a special
> > log message template is used that is specifically for
> > multi-project commits. It would start out with a generalized
> > header that is *only* used when multiple projects are being
> > committed to at once, and then it would include the per-project
> > templates of each of those projects, but perhaps modified in some
> > special way because they're part of this unusual kind of commit.
> >
> > Notice that the resulting template is still a simple, static
> > document. It does not *include* any of the paths being
> > committed. Yet those paths were crucial in determining the
> > content of the template.
>
> Now, that's only one example, I realize. But it seems a very
> plausible one to me... and it didn't take very long to come up with.

And I'm sure that the clever people on this list can come up with more.
  But my challenge still stands: how common is that scenario? Is it
worth it to design this feature based on the extraordinary or should we
focus on the most common case (which is probably more like a single site
log-template or a per project template)?

FWIW, I can replicate that behavior (a little less intelligently) by the
use of inherited properties:

1) each project in that ASF-style repository has a log-template stored
at the top of the project subtree, so commits within the tree get that
template by normal inheritance;

2) the root that repository of contains a log-template with the special
header introducing the cross project commit, then a copy of each log
template from all of the projects and special instructions to delete any
  sub-templates which are not involved in this commit.

This assumes that the "Highest One Wins" scheme for negotiating template
conflicts is used. If instead we did a "All for One" scheme (where all
affected log-templates are concatenated together and the user has to
make the intelligent choices about what goes where), then we would get
the same behavior that your hook performed.

Sure, it isn't as smart as the server hook, and it requires that the top
level log-template be manually kept in sync when the project templates
are changed. I don't think it is too outrageous to assume that log
templates are probably fairly slow moving targets in the majority of
projects. I would expect at most large sites, the log templates are
likely to be tightly controlled anyways (once we get in-tree ACL's)
<DUCK>...

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org