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

Re: Inherited properties document

From: John Peacock <jpeacock_at_rowman.com>
Date: 2005-05-19 18:43:39 CEST

Greg Hudson wrote:
> So I'll outline a poor man's alternative.
>
> * When a new file or directory is created without copy history, we
> look for auto-props to apply to it in a property of the parent
> directory, as well as in the client config. (If auto-props are
> specified in both locations, we have to decide whether to merge them or
> let one override the other; I haven't decided what I think is the best
> answer.) Also, when a directory is created without copy history, we
> copy the auto-props property from the parent. This would all be handled
> by the client.

So this is a write-once scheme; you only copy the auto-props under
limited circumstances during initial creation. Anyone wanting to alter
the autoprops later is stuck with walking the tree and making largescale
changes to the repository. It's also a narrow targeted solution where a
wider scope would solve many problems.

Would you have less objection to inherited properties if we limited it
strictly to single container inheritance? If we only permitted a file
to inherit properties from it's immediately containing directory, and
didn't deal with the [much] harder case of dealing with inheritance in
the tree, would that be acceptable? This is strictly a client-code
change (and I even think I know pretty much where in the code it would
happen, based on my keyword spelunking).

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 19 18:44:21 2005

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.