kfogel@collab.net wrote:
>
> The so-called impossible situation is if you have a chain of
> directories in which two or more both have the P or T property, e.g.:
>
> /myproj/branches/experimental/skunkworks/mybranch_of_myproj/...
> `--- T ---' `-- T ---'
>
> What if both 'experimental' and 'skunkworks' have the T property?
> Marc stipulated we'd have a rule saying that should never happen:
>
>
>>Some error checking can be added to this:
>>- When setting the properties, or on "svn cp" for branching/tagging,
>>assert that the treeroot is not within another treeroot, and assert
>>that the projectroot is not within another projectroot or treeroot
As I mentioned in another message, I now agree that this should only be
reported as an error when a + expansion is attempted either from within
"skunkworks", or referring to "skunkworks". The svn cp or propset that
got us there should not cause an error, though it might be useful to
have it warn.
> I think the valuable insight Marc and you have led us to is that what
> we want is the *effect* of inherited properties, not necessarily
> inherited properties themselves.
>
> Previous discussions concentrated on ways to get directory D's
> property reflected in D's descendents *as a regular property*, and we
> ran into all sorts of hairy questions that way. But if we disentangle
> the inherited properties from the regular properties, and put the
> inherited in their own cache, maybe a lot of those problems go away.
I think they might. It would also allow that cache to include the extra
info needed for this feature, ie: from which ancestor is the property
inherited. Additionally, it would allow easy implementation of erroring
out on "svn propdel/propedit" of an inherited property.
I think it would be a very good idea for any thinking/work on inherited
properties to happen in, or on an experimental branch off of, the
propcaching branch, to avoid undoing any of the excellent work being
done there.
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 13 14:24:39 2005