You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@newton.ch.collab.net> on 2002/05/21 17:49:38 UTC
proposal for sanity check at propset time
We have some properties in the "svn:" namespace that are only
meaningful for files, and some that are only meaningful for dirs:
svn:mime-type ==> files
svn:ignore ==> directories
svn:eol-style ==> files
svn:keywords ==> files
svn:executable ==> files (*)
svn:charset ==> files
svn:externals ==> directories
(* Yes, Unix overloads "executable" to have a meaning for directories,
but that's not what we document the executable property to mean, so I
don't think Subversion should support that overloading.)
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?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal for sanity check at propset time
Posted by Greg Stein <gs...@lyra.org>.
On Tue, May 21, 2002 at 01:06:18PM -0500, B. W. Fitzpatrick wrote:
>...
> I'm +0 on this in general, but in the case of bundled directories (eg
> on Mac OS X), I may very well want to set the mime-type of a
> directory:
>
> $ svn propset svn:mime-type "application/interface-builder" Main.nib
>
> So I'm -1 on the mime-type limitation as I have evil evil plans for it
> in the near future.
Putting on my standards hat, that is an illegal mime type. It should be
something like "application/vnd.apple.interface-builder"
:-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal for sanity check at propset time
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> 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" ??
I think we needn't enforce them on the server, because it's not so bad
to accidentally get these properties on the wrong kind of target --
rather, it's just [probably] an indication that the user didn't do
what they meant to do. Hence the preventative but overcomeable check.
A WC that accidentally has a property on the wrong kind of target
won't behave badly; that property will just be ignored.
> 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"
So for mime-type, we validate the form of the value, instead of
validating target. Sounds good to me!
> 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).
I'm not even sure the client should issue a warning in those cases
(then we'd have to have a way to turn the warning off, for those who
really did mean to do that, etc...).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal for sanity check at propset time
Posted by Greg Stein <gs...@lyra.org>.
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:kfogel@newton.ch.collab.net]
> > 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).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: proposal for sanity check at propset time
Posted by Bill Tutt <ra...@lyra.org>.
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. :)
Bill
----
Do you want a dangerous fugitive staying in your flat?
No.
Well, don't upset him and he'll be a nice fugitive staying in your flat.
> -----Original Message-----
> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> Sent: Tuesday, May 21, 2002 10:50 AM
> To: dev@subversion.tigris.org
> Subject: proposal for sanity check at propset time
>
> We have some properties in the "svn:" namespace that are only
> meaningful for files, and some that are only meaningful for dirs:
>
> svn:mime-type ==> files
> svn:ignore ==> directories
> svn:eol-style ==> files
> svn:keywords ==> files
> svn:executable ==> files (*)
> svn:charset ==> files
> svn:externals ==> directories
>
> (* Yes, Unix overloads "executable" to have a meaning for directories,
> but that's not what we document the executable property to mean, so I
> don't think Subversion should support that overloading.)
>
> 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?
>
> -Karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
default (inherited) properties
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
This message exists only to start a new thread. I do not, personally,
at this time, care about this thread, but I do care about keeping it
out of certain other threads.
Love,
-Karl
"Glenn A. Thompson" <gt...@cdr.net> writes:
> How far would you go here. Would it be child content sensitive? For
> instance make child X with a particular mimetype get a different set of
> defaults than child Y with a different mimetype.
>
> Yeah this could become a new thread:-)
> gat
>
> Bill Tutt wrote:
>
> > No, inherit isn't the proper term here. The more appropriate term is
> > default property values. Each container would have a set of default
> > properties that each new item (i.e. add, and nothing else) in the
> > container would receive upon creation. That's not inheritance. That's
> > defaulting.
> >
> > Bill
> >
> > > From: Glenn A. Thompson [mailto:gthompson@cdr.net]
> > >
> > > Hey:
> > >
> > > Is inherit the proper term here? This is a container relationship no?
> > > Properties which would be set on the files/dirs being inserted into
> > the
> > > parent dir are often properties not applicable to the parent dir
> > itself.
> > > You also get into some pretty tricky "who has final override
> > authority"
> > > issues, including point in-time considerations. Seem like ACLs also
> > > become a topic of discussion in relation to this.
> > >
> > > gat
> > >
> > > Karl Fogel wrote:
> > >
> > > > "Sander Striker" <st...@apache.org> writes:
> > > > > This has probably been shot down before, but what about letting
> > files
> > > > > inherit props set on the directory. This would go for
> > svn:charset,
> > > > > svn:eol-style and possibly svn:keywords.
> > > >
> > > > That's a good question, but kind of separate (maybe would be good to
> > > > start a separate thread on it?).
> > > >
> > > > Assuming that we take all such heritable properties out of the list
> > > > (if we decide to do heritable props at all), we could still sanity
> > > > check the remaining ones, such as the dir-only props.
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > > > For additional commands, e-mail: dev-help@subversion.tigris.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > > For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal for sanity check at propset time
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Hey:
How far would you go here. Would it be child content sensitive? For
instance make child X with a particular mimetype get a different set of
defaults than child Y with a different mimetype.
Yeah this could become a new thread:-)
gat
Bill Tutt wrote:
> No, inherit isn't the proper term here. The more appropriate term is
> default property values. Each container would have a set of default
> properties that each new item (i.e. add, and nothing else) in the
> container would receive upon creation. That's not inheritance. That's
> defaulting.
>
> Bill
>
> > From: Glenn A. Thompson [mailto:gthompson@cdr.net]
> >
> > Hey:
> >
> > Is inherit the proper term here? This is a container relationship no?
> > Properties which would be set on the files/dirs being inserted into
> the
> > parent dir are often properties not applicable to the parent dir
> itself.
> > You also get into some pretty tricky "who has final override
> authority"
> > issues, including point in-time considerations. Seem like ACLs also
> > become a topic of discussion in relation to this.
> >
> > gat
> >
> > Karl Fogel wrote:
> >
> > > "Sander Striker" <st...@apache.org> writes:
> > > > This has probably been shot down before, but what about letting
> files
> > > > inherit props set on the directory. This would go for
> svn:charset,
> > > > svn:eol-style and possibly svn:keywords.
> > >
> > > That's a good question, but kind of separate (maybe would be good to
> > > start a separate thread on it?).
> > >
> > > Assuming that we take all such heritable properties out of the list
> > > (if we decide to do heritable props at all), we could still sanity
> > > check the remaining ones, such as the dir-only props.
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > > For additional commands, e-mail: dev-help@subversion.tigris.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: proposal for sanity check at propset time
Posted by Bill Tutt <ra...@lyra.org>.
No, inherit isn't the proper term here. The more appropriate term is
default property values. Each container would have a set of default
properties that each new item (i.e. add, and nothing else) in the
container would receive upon creation. That's not inheritance. That's
defaulting.
Bill
> From: Glenn A. Thompson [mailto:gthompson@cdr.net]
>
> Hey:
>
> Is inherit the proper term here? This is a container relationship no?
> Properties which would be set on the files/dirs being inserted into
the
> parent dir are often properties not applicable to the parent dir
itself.
> You also get into some pretty tricky "who has final override
authority"
> issues, including point in-time considerations. Seem like ACLs also
> become a topic of discussion in relation to this.
>
> gat
>
> Karl Fogel wrote:
>
> > "Sander Striker" <st...@apache.org> writes:
> > > This has probably been shot down before, but what about letting
files
> > > inherit props set on the directory. This would go for
svn:charset,
> > > svn:eol-style and possibly svn:keywords.
> >
> > That's a good question, but kind of separate (maybe would be good to
> > start a separate thread on it?).
> >
> > Assuming that we take all such heritable properties out of the list
> > (if we decide to do heritable props at all), we could still sanity
> > check the remaining ones, such as the dir-only props.
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal for sanity check at propset time
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Hey:
Is inherit the proper term here? This is a container relationship no?
Properties which would be set on the files/dirs being inserted into the
parent dir are often properties not applicable to the parent dir itself.
You also get into some pretty tricky "who has final override authority"
issues, including point in-time considerations. Seem like ACLs also
become a topic of discussion in relation to this.
gat
Karl Fogel wrote:
> "Sander Striker" <st...@apache.org> writes:
> > This has probably been shot down before, but what about letting files
> > inherit props set on the directory. This would go for svn:charset,
> > svn:eol-style and possibly svn:keywords.
>
> That's a good question, but kind of separate (maybe would be good to
> start a separate thread on it?).
>
> Assuming that we take all such heritable properties out of the list
> (if we decide to do heritable props at all), we could still sanity
> check the remaining ones, such as the dir-only props.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal for sanity check at propset time
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Sander Striker" <st...@apache.org> writes:
> This has probably been shot down before, but what about letting files
> inherit props set on the directory. This would go for svn:charset,
> svn:eol-style and possibly svn:keywords.
That's a good question, but kind of separate (maybe would be good to
start a separate thread on it?).
Assuming that we take all such heritable properties out of the list
(if we decide to do heritable props at all), we could still sanity
check the remaining ones, such as the dir-only props.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: proposal for sanity check at propset time
Posted by Sander Striker <st...@apache.org>.
> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> Sent: 21 May 2002 19:50
> We have some properties in the "svn:" namespace that are only
> meaningful for files, and some that are only meaningful for dirs:
>
> svn:mime-type ==> files
> svn:ignore ==> directories
> svn:eol-style ==> files
> svn:keywords ==> files
> svn:executable ==> files (*)
> svn:charset ==> files
> svn:externals ==> directories
>
> (* Yes, Unix overloads "executable" to have a meaning for directories,
> but that's not what we document the executable property to mean, so I
> don't think Subversion should support that overloading.)
>
> 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?
This has probably been shot down before, but what about letting files
inherit props set on the directory. This would go for svn:charset,
svn:eol-style and possibly svn:keywords.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org