If we could solve our autoprops problem and our log message template
problem using one simple mechanism, that would be very nice.
This mail is an attempt at a formal spec for Greg Hudson's "poor man's
alternative", which he outlined here:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=100409
Goals:
======
I want to get this mechanism (or *some* property-based mechanism) to
the same point of concreteness as the "log message templates via new
hook" proposal, which is described here:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=100358
The hook-based proposal only solved log message templates, not
autoprops, and although it gave repository admins a lot of flexibility
in determining template policy, it had the potential to add
unnecessary complexity in the common cases. We should still consider
it a viable option, but we should also explore property-based
solutions thoroughly.
In http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=100848
Greg Hudson made the the point that since we have a mechanism for
transmitting key-value pairs (properties), we should avoid inventing
new mechanisms to do the same thing if at all possible.
References:
===========
There are several huge threads related to this. I hope you've already
read them, because if you have to catch up on them now, you're
probably doomed. To avoid ugly line-wrapping, the thread prefix is
http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=
The threads are:
* ${PREFIX}325870
"Log Message Templates via new hook."
"Log Message Templates, Autoprops, Inherited Props, etc."
"Log Message Templates vs Server->Client Configuration."
* ${PREFIX}326933
"Inherited properties document"
* ${PREFIX}329707
"Repository-defined autoprops."
Go nuts.
Basic Mechanism Proposal:
=========================
We define certain properties as "inheritable" (Brane, if you tell me
that should be "heritable", then I will go all inflammable on you).
These properties are always about matters of repository policy. The
two examples I'll use here are "svn:autoprops" and "svn:log-template",
even though they don't exist yet, because we all know what they mean.
Hereinafter, "iprop" means "inheritable property".
Things like "svn:ignore" would not be inheritable, because they're
really matters of client-side (working copy) policy.
Note that this means only "svn:" properties can ever be heritable,
because those are the only properties whose meanings Subversion knows
about. If we want truly generic iprops, we'll have to come up with a
different proposal (and I have one sitting in my back pocket, but I'm
not convinced it's worth the extra complexity).
Anyway:
When an iprop is set on a directory D, then new objects created
(without copy history) in D automatically get the same value of that
property. That is, if D has inheritable property P set with value V,
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:autoprops" property, then
creating D/F does not cause file F to have the same "svn:autoprops"
property. Same with "svn:log-template". (There might be iprops that
are appropriate for both files and directories, it just happens that
the two examples I'm using here only apply to directories.)
Inheritance is recursive where appropriate:
- In a working copy, if you do 'svn add SUBTREE' inside D, then
everything under SUBTREE gets D's iprops, if any.
- If you import a tree into a URL that refers to a directory that
has iprops, then the new tree inherits the iprops. (We should
keep in mind potential 'mkdir -p' support, and issue #1328, which
is about having 'import' turn its source into a working copy
in-place.)
- If you do 'svn propset IPROP ...' in a working copy, the client
code notices it, and either attempts to do recursive propsets all
the way down, or errors and tells you to either use "--recursive"
or "--force".
Changing An Iprop:
==================
We have a cache invalidation problem here. Suppose you set the
"svn:log-template" property on empty directory "/myproj" in the
repository. Now you import a source tree under that (or, you check
out /myproj and 'svn add' the source tree, whatever). This sets
"svn:log-template" on directories throughout the imported tree.
What if you want to change your log message template later?
We can't ask you to check out all of /myproj. If it were just
/myproj/trunk, that might be acceptable, but what about all those
branches? No way.
I think the solution is change our policy of disallowing propsets on
URLs. We need to allow
$ svn propset -m "New log msg template." -R svn:log-template NEWVAL URL
to do the right thing: it should recurse, setting that property on all
directories at and under URL.
I'm okay with reversing our no-propsets-on-URLs policy, because one
can't lose unversioned data. Also, we can protect it with a hook: if
your repository doesn't set up the hook, then you can't propset URLs.
I won't go into the details of the hook here; if we decide to do this,
I think the hook interface can be worked out pretty easily, and anyway
I haven't thought carefully about whether the existing 'pre-commit'
hook should do it, or whether we'd want a new 'pre-prop-change' hook.
Same goes for 'svn propdel', of course.
Conclusion:
===========
As long as we have recursive propset support for URLs, and as long as
Subversion knows which properties are inheritable and how, then I
think this can fly, and even be reasonably useable. Without those two
things, I'm not sure how to make the "poor man's alternative" work.
And having thought long and hard about other ways to implement
inheritable properties, I confess I am at a loss: I can't think of
anything else that wouldn't be fatally hard to implement, or fatally
hard to use, or both.
Comments welcome.
-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:10:39 2005