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

Re: svn commit: r23767 - in trunk/subversion: include libsvn_wc

From: Peter Lundblad <plundblad_at_google.com>
Date: 2007-03-12 10:25:26 CET

Erik Huelsmann writes:
> On 3/12/07, Karl Fogel <kfogel@red-bean.com> wrote:
> > dionisos@tigris.org writes:
> - People will generally version non-empty files (meaning 0 will be
> [very] uncommon)
> - The fallback when a file actually *is* empty will be to stat() both
> the text base and working copy files and compare their sizes, meaning
> the fallback cost in that rare case is only 2 stat() calls.
>
> The main reason to choose 0 (given these small costs) is that code
> testing for availability of the field can test:
>
> if (text_size) ...
>
> which I consider very much more readable than
>
> if (text_size == -1) ...
>
> So, in the end, it boils down to personal preference, I guess.
>
Or, if you let nagive value mean "no size recorded", you can do
if (entry->working_size >= 0)

> Yes, this is possible. Anybody else who'd rather have it this way?
>

I don't like using a valid value as "no value" just so it can be conveniently
used in boolean contexts.

Also, why is the difference between unknown value and "value not recorded
because the file is modified" important. I'd say these two boils down to the
same. If the file is modified compared to the base, you catually *don't know*
the real value. I'd say we need to distinguish between present and not
present. If present, use it, else fall back on other means. If we know the
value and know we can use it, write it, else make it not present.

Best,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 12 10:26:02 2007

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.