Philip Martin wrote:
> Julian Foad <julianfoad@btopenworld.com> writes:
>
>>a) When reading any file's mtime from the operating system, validate
>>it and throw an error (refuse to handle the file) if it is
>>unreasonable.
>>
>>b) Always preserve whatever mtime the operating system gives, ensuring
>>that our "entries" file can represent it, reasonable or otherwise.
>>This might involve the year being negative or more than four digits
>>... yuck.
>>
>>c) Ensure that we always write a well-formed "entries" file by writing
>>some valid but fairly unreasonable time string instead of the totally
>>unreasonable mtime of the file.
I don't like that.
>
>
> I don't like any of those, I'd prefer one of:
About (a), is it the refusing to handle the file that you don't like? I saw
that as a positive feature. Note that we refuse to handle files that have
names that we can't cope with. Or is it something else, such as a possible
speed penalty, that you don't like?
> d) Remove the checking from the string-to-mtime conversion so that
> the conversion reproduces the original "unreasonable" mtime and
> everything just works.
I don't like that because it perpetuates the ill-formed time strings. (Even
though they'll no longer be "ill-formed" from our parser's point of view, they
would be in everybody else's view.)
> e) Add checks to the mtime-to-string conversion so that it matches
> the string-to-mtime conversion, if the checks fail just omit the
> timestamp from the entries file. Everything just works but some
> operations will run a little slower. (This is (a) but without
> throwing an error.)
That one is quite a nice solution.
What I didn't make clear is that the time-to-string conversion is used not just
for the mtime but for three other times in the "entry" as well. There is a
decision to be made whether to check for validity when the mtime when is read
from the operating system or when the mtime is converted to a string or when
any time is converted to a string. This last, checking any and every time that
is converted to a string, has robustness in its favour. Otherwise I won't be
confident that the mtime is the only source of invalid times.
I suppose my preference now is for (e) applied to all times in the "entries"
file (not just the mtime), and possibly (a) as well. There's no particular
need for (a) as well, and I suppose you could argue that it would be
gratuitously refusing to handle something that we could handle, so I'll drop
that idea unless you change your mind.
So, (e) it is. Is it valid to apply it to all of:
text_time (mtime)
prop_time
cmt_date
lock_creation_date
?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 2 00:17:22 2005