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
Received on Fri May 27 21:38:09 2005