Hi All,
I haven't been ignoring this thread, I've been laid low with illness
the last couple of weeks...
...Anyhow, when I finally got back to this I see that a lot of folks
are itching for an inheritable property solution. So for now I'll
defer on the open questions re the proposal in the wiki. Instead
let's talk inherited properties. I suspect that if we don't view
inheritable props through an "everything an pony too" lens, if we
agree on some basic limitations and easy to explain, well-defined
behavior, then we can make this work[1].
[1] Understand that I am emotionally scarred from implementing
mergetracking/mergeinfo, where we tried to include the pony. We got
the pony in, but it trampled me on its way -- I don't want to go down
that road again!
On Thu, Jan 5, 2012 at 4:17 PM, Konstantin Kolinko
<knst.kolinko_at_gmail.com> wrote:
> I like TortoiseSVN way because
> a) it is already known for several years and it works
> b) it leverages existing support for path-based security, for svnsync
> and dump formats.
On Thu, Jan 5, 2012 at 2:42 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> I think most of use-cases can be solved by existing mechanism without
> inventing something new:
> 1. auto-props
> TortoiseSVN already has 'tsvn:auto-props' property [1]. Which used to
> automatically set properties for added files. It would be nice if
> Subversion core support this property.
I don't think we want to leverage tsvn:autoprops because the current
Tortoise behavior is lacking some functionality we almost certainly
want. For example, while TSVN can inherit the tsvn:autoprops property
from within a working copy it can't inherit from the repository if the
WC doesn't have the required property set. Also tsvn:autoprops
affects imported files only when those files are imported into a
directory with tsvn:autoprops explicitly set (there is no
repository-side inheritance akin to what happens for additions in the
WC).
Here's a use-case keep in mind that shows what I think we need to
support at a minimum:
A repository like svn.apache.org/repos/asf which has many (over 100 in
this case) projects that, while they have some common organizational
requirements, are largely independent and quite likely have differing
requirements for autoprops and ignores. A project administrator
should be able to set an inheritable svn:auto-props property on the
root of their project (i.e. s.a.o/repos/asf/subversion) and have it
apply to across the project via inheritance. So even if a user checks
out s.a.o/repos/asf/subversion/trunk then adds new files to their WC
the auto-props should apply. If we can't support a basic use-case
like this I think we need to pursue an alternative solution that does
(like that in the wiki).
So if we are going to do this right, we need to implement true
inheritable properties, and use our own property (e.g. svn:auto-props)
rather than trying to support tsvn:autoprops. I don't believe we want
different behaviors for tsvn:autoprops when using the command line vs.
Tortoise.
> 2. ignores
> We can add svn:global-ignores property to define global (recursive) ignore mask.
Which requires inheritable properties right?
> 3. store-plaintext-passwords
> Since most used of platforms already supports password encryption
> (Windows, MacOS, KDE, GNOME) I think we can safely just change to do
> not store plaintext by default.
As you may have seen, Mike Pilato is investigating the problem of
credential caching, see
http://wiki.apache.org/subversion/EncryptedPasswordStorage So I'm
limiting my responses to inheritable properties in general and
auto-props and global-ignores in particular.
On Thu, Jan 5, 2012 at 3:03 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> The approach TortoiseSVN and some other clients take does work pretty
> nicely but I also think they reveal the short comings in using
> properties. For convenience, TortoiseSVN does not force you to set
> these properties on every folder and instead will walk to the root of
> your WC to find them, but then this also exposes the problem that if
> you did not checkout the folder that has those properties you are back
> to square one.
Exactly, so what would an inheritable solution look like in this case?
(Yes, lot of this is similar to what Konstantin suggested earlier in
this thread).
Say our magic inherited svn:auto-props property is set on ^/subversion.
For the sake of completeness let's first look at the simple case: We
check out ^/subversion. Here things are relatively easy:
1) When required we walk the WC and find the necessary inheritable
property on the root of the WC. Done.
Even here there complications to consider. How to handle mixed-rev
working copies being the simplest: With svn:mergeinfo we don't inherit
across mixed-rev boundries, because svn:mergeinfo is in a constant
state of flux and we can easily contact the repository to obtain the
correct inherited mergeinfo (a merge by definition needs contact with
the repos, so there are no worries about disconnected operations).
For auto-props and global-ignores though, the client will want to know
about this property during what have always been disconnected
operations (e.g. svn add) so we can't(?) start contacting the
repository. And even if we did, it's likely these properties are
fairly static and almost never change, so most of the time we'd end up
with the same property value we could have gotten from the WC root.
So I propose we simply ignore mixed-rev working copies (which AFAICT
is what Tortoise does today with tsvn:autoprops). Yes this means that
a user could potentially use out-of-date inherited properties, but
let's keep in mind that for auto-props and global-ignores:
A) repository admins still ultimately need to enforce their
auto-props and global-ignores standards via hook scripts
B) Anyone can still hack up a client to ignore these properties
(we're not suggesting any of these proposals provides absolute
proof against malicious users).
Now for the slightly more complicated case, we checkout
^/subversion/trunk and so don't have the inherited property set on the
root of the WC. We could:
2) Check the repository as needed: We can't inherit the property from
within the WC, so we ask the repository. This has the same drawback
as described above, previously disconnected operations suddenly
require access to the repository. This seems a deal-breaker to me.
Or
3) Cache inherited properties in the WC during checkout/update/switch:
If the WC could cache the latest inheritable properties not explicitly
set on it's root then we can keep our disconnected operations (that
require these props) disconnected. Maybe inheritable properties will
need their own namespace (e.g. svn:inherit:PROPNAME) to make it easier
to differentiate between them and 'normal' properties. The drawback
to this approach of course is similar to #1 above, we might
unknowingly use out-of-date inherited properties, but the same defense
of that behavior applies here. I think this is the better approach.
On Tue, Jan 3, 2012 at 9:20 PM, Konstantin Kolinko
<knst.kolinko_at_gmail.com> wrote:
> Mechanism to enforce configuration updates:
> I think that it could be similar to what happens when you try to
> commit property changes on a directory. If your directory is not up
> to date the commit is rejected and you are asked to update your WC.
I think this is looking suspiciously Pony-like :-) Let's say we add
files that get the svn:eol-style property set via an inherited
svn:auto-props property. When we go to commit the commit fails
because the inherited inherited value of the svn:auto-props has
changed. Ok, we update, get the new inherited property, then...what?
Can we commit, because if so we still have the old eols, so why bother
rejecting the commit? Or does update detect this and fix the eols?
Teaching update to "fix" the working copy based on a new set of
inherited properties is exactly the kind of added complexity that has
kept inheritable properties from being implemented. If the inherited
svn:global-ignores property changes, then is update going to
schedule/unschedule local additions? I draw the parallel to
mergetracking and its effort to do the right thing when merging into a
WC with switched, missing, and shallow subtrees. Yes, it has been
made to work, but is it really worth the complexity and explosion of
edge cases? And at least svn:mergeinfo is a stationary target,
generic inherited properties are a moving target; who knows what new
props the future will bring, and we'll need to have update account for
changes in them all.
We'll also need to consider how switched subtrees and externals
inherit properties.
Switched subtrees with the inherited property on the root of the
switch are handled like case #1. If the root of the switched subtee
doesn't have the explicit prop then again we could cache it like case
#3 when the switched subtree is created. We can probably take a
similar approach to externals, but I'll hand-wave a bit on that right
now.
> That is why I believe it makes sense for SVN to
> support it natively using an approach something like described in the
> wiki. Or at least weigh that approach versus using properties within
> the repository.
Disclaimer: I'm not giving up on the approach detailed in the wiki
just yet, I only want to explore the inheritable properties approach.
On Thu, Jan 5, 2012 at 4:52 PM, Hyrum K Wright
<hyrum.wright_at_wandisco.com> wrote:
> As I recall, there were a few reasons why inherited properties haven't
> been implemented. One is the client-side storage and lookup, which
> wc-ng has helped with. The other is what to do with non-checked out
> parent directories, which you mention above. Another problem is the
> various authz issues, similar to the infamous issue 3242 problems we
> had with copy and move.
Maybe we can make a special case for inheritable properties, simply
state that by definition, if you set an inheritable property on a
path, then users, even those who don't have access to the path, but do
have access to the path's children, can inherit the property.
For example if a user has access to foo/bar/baz, then that user can
inherit properties from foo, even if he doesn't have access to foo
itself. All the repository has to tell the client is, "Path
foo/bar/baz inherted property NAME=VAL", it doesn't even need to say
where it came from.
If we don't make this exception then it seems to me that inheritable
properties are dead in the water, at least as far as being a useful
solution to "server" dictated auto-props and global-ignores.
> And lastly, we haven't yet hammered out the
> issues surrounding what to do with potentially conflicting properties
> within the tree--though that might have been specific to log message
> templates, now that I think about it.
We could chose to make things simple and follow the svn:mergeinfo
model of inheritance:
a) If a path has an explicit given property then it doesn't inherit
that property; the explicit value is the complete value.
b) If a path doesn't explicitly have a given property then it inherits
that property from its nearest parent with the property explicitly set
on it.
No merging of inherited with explicit properties, so no conflicts,
just keep it simple.
Essentially the same approach for svn:auto-props and
svn:global-ignores, we do the same thing the current hierarchy of
configuration does today: There is no merging of lower priority
configuration, it's simply a matter of choosing the option value from
the highest priority level the option is specified.
Which would be, from highest to lowest priority:
Command-line options*
Explicit/inherited svn:auto-props/svn:global-ignores
Per-user runtime configuration (${HOME}/.subversion/*)
The per-user Registry values (Windows Only)
Per-machine runtime configuration (/etc/subversion/*)
The system-wide Registry values (Windows Only)
* Yes Johan, your arguments for making CL options have the highest
priority did sway me :-)
On Fri, Jan 6, 2012 at 7:16 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> Come to think of it: using properties has the nice advantage that
> these "configurations" come along when a project is branched or
> tagged. Which is what most users would expect, I guess.
Except when they don't expect it...
The configurations would certainly come along if the path on which
they were explicitly set was copied (just like any other versioned
prop), but I don't think inherited properties should be copied,
because then if the inherited properties on the destination differ
from the copy source, then we'll need...wait for it...explicit subtree
inherited properties on the destination (i.e. explicit properties that
appear, seemingly from nowhere, on the copy destination).
Properties popping into existence has proved quite confusing with
svn:mergeinfo, where it is regrettably necessary in some cases, but
for generic inherited properties do we really need this behavior? Why
not simply state that inheritable properties are handled *exactly*
like any other versioned property w.r.t. copies and moves, so users
should plan accordingly.
I don't mean to imply that there won't be cases where we might prefer
to have inherited properties copied, it's just that neither approach
is perfect for every use case, so why not go with the behavior that is
simpler to implement, simpler to explain, and doesn't sprout new
properties out of the ether?
~~~~~
So, do we think we can live with inheritable properties with the
aforementioned restrictions?
Paul
Received on 2012-01-17 00:51:33 CET