[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: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2007-03-12 08:52:29 CET

On 3/12/07, Karl Fogel <kfogel@red-bean.com> wrote:
> dionisos@tigris.org writes:
> > Log:
> > --- trunk/subversion/include/svn_wc.h (original)
> > +++ trunk/subversion/include/svn_wc.h Sat Mar 10 03:22:25 2007
> > @@ -1384,6 +1384,12 @@
> > */
> > const char *changelist;
> >
> > + /** Size of the file after being translated into local representation,
> > + * or 0 if unknown.
> > + * @since New in 1.5.
> > + */
> > + apr_off_t working_size;
>
> Hmm, why "0" for unknown? Since files can be 0 bytes long, why not
> use -1 or some other impossible number to represent "unknown"?

I thought about it a while and figured:

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

> (Later, in r23770, you added text saying "negative if the file is
> locally modified so the working size couldn't be recorded". That
> would become -2 or some other specific value, I guess.)

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

Bye,

Erik.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 12 08:52:45 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.