Greg Hudson <ghudson@MIT.EDU> writes:
> On Thu, 2005-06-30 at 15:22 -0500, kfogel@collab.net wrote:
> > We define certain properties as "inheritable" (Brane, if you tell me
> > that should be "heritable", then I will go all inflammable on you).
>
> I don't think we can correctly hardcode which properties should be
> inherited and which shouldn't be. The idea that svn:ignores shouldn't
> be inherited and svn:log-template should be seems bizarre to me, for
> instance.
Hmm, does that seem bizarre? Log message templates are a matter of
project policy. Ignorable files are fuzzier: they're a matter of
per-directory policy, in a sense (I was wrong to state that they were
purely a working-copy-side issue, though, mild braino there, sorry).
I can see that there are circumstances under which svn:ignore should
be inheritable, yes. It's hard for me to imagine that it would be
inheritable where svn:log-template would not be, but whatever. Your
overall point seems solid: that we shouldn't try to hardcode, but
instead have a general mechanism.
> Perhaps we could define a default list, and have an svn:inherit property
> to override the default.
Well, that's very close to what my other, more general proposal was,
the one I had in my back pocket. It called the property "svn:iprops"
instead of "svn:inherit", but basically you can tell where it was
going. Here it is. It's going to look mighty familiar:
Generic Iprops Basic Mechanism Proposal:
========================================
We define a new property named "svn:iprops". Its value is a
newline-separated list of property names.
When "svn:iprops" is set on a directory D, then new objects created
(without copy history) in D automatically get properties copied from D
according to "svn:iprops". That is, if D has property P set with
value V, and "svn:iprops" lists P, then new objects created in D also
get property P with value V.
EXCEPTION: Properties known to be meaningless for files are not copied
to files. For example, if D has an "svn:ignore" property, and
"svn:iprops" on D lists "svn:ignore", then creating D/F does not cause
F to have the same "svn:ignore" property. Naturally, this stipulation
only applies to "svn:" properties. Subversion doesn't know the
semantics of other properties, so it always copies them promiscuously
if they're listed in "svn:iprops".
The "svn:iprops" property itself is always inherited to directories.
That is, if D has a "svn:iprops" property, then that property is
copied to subdirectories created under D, but not to files. This
happens whether or not "svn:iprops" lists itself.
Inheritance is recursive where appropriate. In a working copy, if you
do 'svn add SUBTREE' inside D, then everything under SUBTREE gets the
properties listed in D's "svn:iprops" property, as described above.
The same is true if you import a tree into a URL that refers to a
directory that has "svn:iprops" set. (Similar concerns apply to
potential 'mkdir -p' support, and to fixing issue #1328, which is
about having 'import' turn its source into a working copy in-place.)
If you do 'svn propset svn:iprops ...' in a working copy, the client
code notices it, and either attempts to do recursive propsets all the
way down to set things up "as though svn:iprops had always been
there", or errors and tells you to use "--force" or "--recursive".
Changing An Iprop:
==================
We permit
$ svn propset -R svn:iprops NEWVAL URL
to work. And it should do the right thing: recurse, setting that
property on all directories at and under URL, *and* setting any
properties that would be a consequence of the new "svn:iprops" value
appropriately.
Same goes for 'svn propdel', of course.
I guess this means we also must permit other properties to be set
remotely on URLs (because if you want to change your log message
template, that's the obvious way to do it). I'm still okay with
reversing our no-propsets-on-URLs policy, because one can't lose
unversioned data, and we can protect it with a hook (details TBD).
I have an uncomfortable feeling that there are more edge cases, now
that we've introduced "svn:iprops" instead of just some hardcoded
inheritable props, but I thought I'd post this now just to start
somewhere.
Thoughts?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 30 23:48:37 2005