You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2005/05/27 17:53:02 UTC
Log Message Templates, Autoprops, Inherited Props, etc.
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
Re: Log Message Templates, Autoprops, Inherited Props, etc.
Posted by John Peacock <jp...@rowman.com>.
kfogel@collab.net wrote:
> + 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.
I don't see why the severable working copy issue is _that_ big a deal.
According to my revised "design" document, the iprop is stored in the
directory itself, so the client code only needs to know that it has to
check for any iprops in its containing directory. Thus the WC files are
as completely severable now as they were before, with only the iprops
being duplicated at each level in the WC.
But see below...
> 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.
The advantage of Greg's proposal was that the inheritance activity was
completely client-side (create directory without history causes parent's
iprops to be added) as well as not requiring complicated server side
behavior. Of course, the lack of tree-inheritance could also be seen as
a weakness. ;-)
I have been very distracted with other things, so I haven't been able to
sit down and think through Greg's proposal in detail. At a glance,
however, it should give us the ability to do everything we've been
talking about for inherited properties (including specialized behavior
like autoprops, log-templates, and even custom keywords). We could
provide some syntactic sugar (like a script) which would make it much
easier to populate iprops into an existing tree. Once established, the
normal directory creation should propagate the iprops as desired.
The one big remaining problem is whether specialized iprops (like
autoprops) override or append to the client config-file properties. So
I propose that iprops have a trinary nature:
1) name
2) append/override
3) value
Thus, autoprops would probably append to any existing value, whereas a
log-template would probably override.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org