[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: proposal for sanity check at propset time

From: Glenn A. Thompson <gthompson_at_cdr.net>
Date: 2002-05-21 21:26:05 CEST

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" <striker@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
Received on Tue May 21 21:21:50 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.