For 1.3, we've been talking as though log message templates
unquestionably depend on coming up with some sort of generic
server->client configuration transmission mechanism.
I think it'd be good to step back for a moment and look at the actual
requirements for log message templates, without making any assumptions
about how they'd be implemented.
Here's a dialogue on how log message templates should behave:
Q: What is the behavior we want?
A: When 'svn ci blah1 blah2 blah3' brings up an editor, the editor
should be already populated with the log message template (in
addition to the changed-paths information that we already
insert).
Q: Yes, but what is this template exactly? Is it per-repository?
Or is it "per-project"? And if the latter, isn't that really
the same as saying "per-directory", since Subversion doesn't
know anything about projects?
A: Good question. Let's look at what CVS does. Even though we may
not want to do things the same way as CVS, at least it's a
starting point, and this is a CVS parity feature after all.
In CVS, there's a repository-side 'CVSROOT/rcsinfo' file, in
which each line is "REGEXP TEMPLATE_FILE". If the directory
you're committing in matches REGEXP, then TEMPLATE_FILE is used
as the log msg template.
Q: What happens when you commit to multiple directories at once,
and they match different lines, so that you have multiple
template files to deal with?
A: The first match is used, and the others are ignored.
Q: Oh. That's... interesting. What about transmission? How does
the CVS server communicate the template data to the client?
A: Well, if access is local, the client just reads the template
from the repository each time. If it's network access, then the
template for each directory D is stored in D/CVS/Template at
checkout time.
Q: What if the template changes in the repository after checkout?
A: It does not get updated in the working copy.
Q: Oh. That's... interesting. So, when it's network access, and
each template is stored in D/CVS/Template, then the client still
uses the first available template, if multiple templates (i.e.,
target directories) are involved in a commit?
A: Well, no, the whole system appears to be totally broken over
":pserver:" in CVS 1.12.9, and the template apparently never
gets consulted at all -- you don't see it when the log message
editor pops up. But I'm sure that's just a bug.
[editor's note: I do not think we want to emulate CVS's behavior here.
Even in the non-buggy behavior, CVS has totally punted on handling
conflicting templates. CVS has apparently made some attempt to avoid
an extra network turnaround at commit time, by storing the template
locally, but it has no provision for *updating* that template when the
copy in the repository changes. Yuck.]
Q: Oh. That's... interesting. Never mind the question of network
turnarounds for the moment. Let's focus on how can Subversion
could handle this problem of overlapping templates?
A: Okay. Well, we could just have a single, repository-wide
template, that every commit to that repository would use.
Q: But that would suck for repositories like (say) the ASF, which
store multiple independent projects in the same repository. Can
you think of anything else?
A: Yes. Fitz came up with the following brilliant idea. Note how
it does not involve a generic server->client configuration
mechanism.
First, we just agree to eat the extra network turnaround. The
idea is that the functionality we would gain would be worth it.
When you do a commit that would pop up an editor, the
editor-calling function first sends a new request to the server,
svn_ra_get_log_message_template(paths), meaning: "Here are all
the paths I'm committing, hand me the appropriate log message
template please."
On the server side, this causes hooks/log-message-template to be
invoked. If the hook doesn't exist, then the response that
comes back to the client just says "no template", and the client
behaves as it does today.
If the hook does exist, it takes a newline-separated list of
paths on stdin (the paths being committed), and sends a log
message template to stdout. The beautiful part is that it is up
to the server -- up to custom logic -- to decide how to handle
the multiple-template issues. The hook *could* just ignore the
incoming paths and send the same template back every time
(indeed, we'll probably ship with a default that does that, and
most admins will probably just trivially tweak that default).
But you could implement any logic you want. All the information
is there. We can make the hook take the author as a parameter,
too.
I don't know if this hook should have a way of stopping the
commit, the way pre-commit does; my instinct is it shouldn't,
because it has the option of sending back a template that just
tells the committer to consider aborting because he's committing
in an incoherent set of directories. But whatever, that's a
minor question to be settled in later discussion.
Anyway: no server->client configuration transmission mechanism here.
Now, maybe s->c config mechanism would be useful for other features
(mime types? autoprops? what else?). But I don't think we should
prefer such a mechanism for log message templates just because it
might be reusable. Instead, we should decide what semantics we want
for log message templates, and implement those in the most direct way.
I'm comfortable with the extra network turnaround in the above
proposal, and I like its user-visible behavior. By definition, it
always does the right thing -- if it didn't, the repository admin
would fix the hook :-).
Of course, there are *lots* of other ways to implement log message
templates. Some of them would involve s->c config transmission;
others might involve directory properties, perhaps with some new sort
of inheritance mechanism. After talking about some of these
possibilities, Ben and Fitz and I saw that
a) They could work, and
b) They all get hairy pretty quickly.
What I like about Fitz's proposal is that it doesn't get hairy. It's
simple and (I think) completely solves the problem. So:
1. Does anyone disagree with the _semantics_ of Fitz's proposal,
that is, the user-visible behavior of log message templates
(ignoring network-related performance issues)?
2. Does anyone feel that the extra turnaround is enough of a
concern that it should maybe sink this proposal?
I don't mean to prematurely focus discussion on this one proposal. If
you feel that an equally viable solution has been ignored, or that
there's some important part of the problem being overlooked here, just
speak up.
The main thing I wanted to do is separate "Log Message Templates" from
"Server->Client Config Transmission". One is the feature users
actually want; the other is *a* way to implement it.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 17 00:53:02 2005