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

Log Message Templates, Autoprops, Inherited Props, etc.

From: <kfogel_at_collab.net>
Date: 2005-05-27 19:53:02 CEST

I have read (again) over the entirety of these threads:

   "Log Message Templates vs Server->Client Configuration."
   "Inherited properties document"
   "RFC: Log Message Templates via new hook."

Here is a summary (fair, I hope, but not neutral) of the current state
of things.

* Question: How shall we implement log message templates?

  There are two proposals on the table right now. One is to use a
  server-side hook, the other is to use inherited properties.

  + The hook proposal is pretty well-specified at this point. There
    are no mysteries about how to implement it or about how it would
    behave. Various objections to it were raised during our
    discussions, but I believe all were satisfactorily resolved except
    these two:

     - It adds an extra network turnaround.
     - It might be over-complexification of a simple problem.

  + The iprops proposal is not as well-specified at this point.
    Although much progress has been made on determining iprops'
    behavior (thanks to John Peacock starting us out with a detailed
    preliminary document), we are still nowhere near knowing how to
    implement it. Even if we knew exactly how it would behave, we
    suspect there would be difficulty implementing it
    reliably/efficiently with severable working copies.

    Greg Hudson proposed a drastically simplified version of iprops.
    It wasn't clear to me if he was just trying to throw some new
    ideas in to the mix, or if it was meant as a serious let's-do-this
    proposal. The discussion that ensued didn't go anywhere very


  First, I am not saying "Based on the above, we must obviously
  implement the hook proposal." Not at all. I am, however, noting
  that at this point it is quite possible to implement the hook
  proposal, but not possible to implement the iprops proposal (nor
  even to estimate its difficulty). Until that situation is
  rectified, it's a showstopper for iprops.

  Since I am personally unconvinced by iprops (I believe it's very
  complex to implement and is likely to turn into a maintenance
  nightmare -- a bug source), I'm not an appropriate person to drive
  that discussion, although I'm happy to follow it, comment on it, try
  to summarize it, etc.

  If someone has ideas for how to move the iprops discussion toward
  implementability, please post. It has promise, and I don't want to
  to shut it down prematurely. I'm just not sure where to go with it.

* Question "Why are we talking about log message templates instead of
  autoprops?" Also: "Shouldn't log message templates and autoprops
  use the same mechanism?"

  Brane has asked why we're talking about log message templates
  instead of autoprops. On a semi-related note, he's stated that it
  would be nice if we could come up with one mechanism that would
  solve both problems.

  If the problems turn out to be related, I agree, it would be nice,
  but I think it's an intellectual mistake to *start* from that
  assumption. And, to answer the first question, we started talking
  about templates because, well, that's what I first posted about :-).

  The best way to solve autoprops would be to start another, entirely
  separate thread about it. Just as with the log message templates
  thread, we should start out by defining the problem and our goals
  clearly. Then we can start looking at solutions. If we see the
  solutions converging on the same sorts of things as the log message
  templates thread, then we'll know we really have two special cases
  of the same problem, and can act accordingly.

  I will make a separate post to start an autoprops thread.

* Question: "Do we need to consider GUI clients specially when
  designing a log message templates feature?"

  This is really just a special case of one set of objections that
  came up during the log message templates discussion. I personally
  believe that discussion is starting to come to a more-or-less
  satisfactory conclusion. But the thread is so meandering that I'm
  not sure everyone would agree with that assertion, and so I'm drawing
  attention to it here. Please see
  for details.

  None that I know of. If the thread turns out not to be resolving
  itself, then we'll cross that bridge when we come to it.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 27 20:31:19 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.