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

Re: [PATCH] check name svn special properties

From: John Peacock <jpeacock_at_rowman.com>
Date: 2005-08-02 17:27:08 CEST

Julian Foad wrote:
> John Peacock wrote:
>> Just because the node props have a client-side effect[1] doesn't mean
>> that there isn't a situation where being able to affect[1] them from
>> the server is desireable.
> Please could you concoct an imaginary but realistic use case and
> demonstrate how this proposal would adversely affect it? I still can't
> see it.

I wasn't thinking *specifically* of this proposal, but rather the
"server resident project defaults" feature, which is largely covered by
this issue:


Suppose we add this feature now and then later implement a server config
mechanism (possibly through inheritance). Future client code must now
support both the hard-coded list, plus the server-pushed configurations,
with the complication of precedence (client overrides server OR server
overrides client OR additive OR ???). Anytime the client contains a
hard-coded list of acceptable values, it then becomes harder to support
repository defaults. I have no problem with the *client* enforcing
certain values; I just think the best way to store the list of legal
values is on the *server*.

For an imaginary scenario, a project could decide that, for whatever
reason, they want to forbid certain otherwise legal svn:* properties
(say svn:eol-style because they discover that it has been used in the
project incorrectly in the past). With a hard-coded list in place on
the client, it becomes much more complicated to support that.

It's not that big a deal. I'm just trying to look at the long view and
how this [admittedly useful] feature might interact with other features
not yet complete.


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 Tue Aug 2 17:28:22 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.