On Tue, May 21, 2002 at 11:08:24AM -0700, Bill Tutt wrote:
> Totally enforce useful rules for important Subversion owned properties.
> Rules on important properties are good for your data store's sanity.
> That's a huge +1 from me. :)
And a +1 from me.
> > From: Karl Fogel [mailto:email@example.com]
> > Sent: Tuesday, May 21, 2002 10:50 AM
> > Since Subversion manages the "svn:" property namespace anyway, maybe
> > we should protect against setting such properties on the wrong kind of
> > target? Of course, user can pass --force to override:
> > $ svn propset svn:mime-type "text/plain" .
> > Error: "svn:mime-type" is for files, blah blah, use --force to override
> > $ svn propset --force svn:mime-type "text/plain" .
> > property `svn:mime-type set on '.'
> > $
> > Thoughts? Objections?
For some properties, you may need *two* locations for enforcement. One in
the client, but also one in the server.
All but svn:mime-type are pure client properties. The server is completely
ignorant about them; thus, the props only need client-side enforcement. I
think you should also analyze what library uses them, which then states
where the enforcement occurs.
But you still have the question: if libsvn_wc enforces svn:executable to
only be on files, should we also encode that in the FS so that somebody
cannot "go straight to the FS, insert a 'bad' property, and monkey with the
WC when it finally receives the property" ??
Back to svn:mime-type... the server *does* use this, by returning it in the
Content-Type header for a GET request (actually, it appears in other places,
too). Thus, it is appropriate to have "deep" validation on it: both client
and server side. Per Fitz's point, dirs might also have a mime type, but we
should validate that it has the form "majortype/subtype"
My personal preference is to provide enforcement only on the client side,
yet allow the client to deal gracefully with server-side-monkeyed
properties (issue a warning). The mime type should be enforced by
mod_dav_svn and libsvn_client (or libsvn_wc if the WC looks at it).
Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue May 21 22:51:10 2002