John Peacock <jpeacock@rowman.com> writes:
> You're right; a sufficiently advanced hook script could query the
> repository for more information. Would we include an example script
> which would do this data-diving or expect that to be a lesson for the
> admin (I'm not being completely facetious)?
Yes, I think we should do that. This stuff isn't necessarily obvious.
A little support from us could save admins a lot of time!
> I still think that emergent behavior is more robust than an external
> program which would have to retrieve information to build the
> template. We have to ask if the added freedom for the hook script
> outweighs the possible complexity of the [re]implementation by each
> site admin.
Absolutely; that's a worthwhile question.
First of all, like you said above, we should prevent the
re-implementation issue by shipping some common template hook scripts
with Subversion itself. When I say "we", I really expect that these
things would be contributed, in the natural course of things, but in
any case we should see to it that it happens.
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.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 20 18:48:10 2005