Re: svn commit: r8957 - in trunk/subversion: include libsvn_subr

Julian Foad <julianfoad@btopenworld.com> writes:

> I guess it was totally obvious to you, but my initial reaction to this
> log message was "Why, exactly? I don't recall a recent discussion of
> it. Is there a more concrete reason than just to make it less likely
> to overwritten accidentally? Why this file and not other files?"

It seemed completely uncontroversial to me.

> Now I think I see the answer: for consistency, i.e. for the same

Yes, it was the only file in .svn that was not read-only (and making it
read-only in the repository appears to be harmless).

> reasons that we already make most of the other important files
> read-only (not "README" which doesn't need to be preserved, but nor
> "empty-file" which does).

Those are already read-only in .svn.

> In cases like this, don't we prefer to try the usual case first, and
> then fall back to the unusual case? After repositories and working
> copies have been through this code once, the expected case will be for
> the file to be read-only, so it would be best to start by setting it
> read-write before trying to open it.

The code is optimised for the usual case: every format file gets
created, very few get overwritten.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org