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
clear.
SUMMARY:
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.
ACTION:
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
http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=325870
for details.
ACTION:
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.
-Karl
---------------------------------------------------------------------
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