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

Re: SVN can't update write-protected files?!?

From: Ben Reser <ben_at_reser.org>
Date: 2005-01-17 00:49:23 CET

On Sun, Jan 16, 2005 at 06:06:49PM -0500, Greg Hudson wrote:
> I can understand the practical frustration here, but your proprietary
> development environment is essentially saying "no other tools should
> modify this file." Subversion could be modified to ignore the read-only
> bit, and it might not be a terrible idea (we know the file is under
> version control, so we sorta own it, so it might be okay to override the
> read-only bit on it; also, it would probably be a one-line change), but
> it's not really worth a ?!? in the subject line that we don't do that.
> Would you complain that your editor won't edit the file like you want
> to, that a perl script won't modify the files like you want to, and so
> forth? Just what do you expect the read-only bit to do?

I am very strongly of the opinion that we should not try and "alter"
Windows filesystem behavior to match *nix platforms. I understand the
problem with certain development platforms wanting to use that bit in a
certain way. But to fix this would require us to break people that are
expecting us to follow the platform's permissions. We can't have it
both ways so we should behave per the platform norms.

I'd be okay if we added a configuration option to force us to ignore
this. But only in the config file (not command line) and only default
to our current behavior. But I'm not sure it's worth it to do this.

Ben Reser <ben@reser.org>
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 17 00:51:19 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.