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

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

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2004-03-10 18:17:24 CET

Philip Martin wrote:
> 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.

It probably is. That just wasn't clear from reading the log message.

>>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.

Ah - not in my Subversion source working copy where I looked at them while writing that e-mail - but then that WC is about a year old, and I see in a more recent WC that you are correct.

>>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.

Good point. Sorry for the noise.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 10 18:16:33 2004

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.