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.koli...@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 <i...@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 <markp...@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.koli...@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.wri...@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 <jcor...@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
