[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Log Message Templates vs Server->Client Configuration.

From: <kfogel_at_collab.net>
Date: 2005-05-17 00:17:15 CEST

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

   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

      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,

      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.


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.