> Folker Schamel wrote:
>
>> Branko ÄŒibej wrote:
>>
>> > C.A.T.Magic wrote:
>> >
>> > > I have no (FAT) filesystem available with only a 2 second resolution,
>> > > but i could think of a situation like this
>> > > ! imaginary example !:
>> > >
>> > > svn update
>> > > #=> creates file1 with current time 00:00:00.10
>> > > #=> FAT rounds this to 00:00:02
>> > > #=> svn stores that time as 'last modified' in its entries file.
>> > > #=> user modifies a character in the file no size change)
>> > > # at 00:00:01.30 -- FAT rounds this to 00:00:02 again.
>> > > svn commit
>> > > #=> does nothing - file time hasn't changed, size hasn't changed
>> > > #=> user thinks everything is committed and deletes his WC,
>> > > or a release version is built without the required fix etc.
>> >
>> > This is a very contrived example. First, it's very unlikely that a user
>> > would do something like that in under 2 seconds.
>>
>> Then why is there a need for a sleep at all?
>
>
> You're quoting out of context. My objection to this particular example
> was that it's used to demonatrate a case of "data loss", but this is not
> data loss.
But your argument is wrong: Either his sample is possible,
then you can loose data in that way; or his sample is not possible,
then there would be no need for a sleep at all ;-)
> The sleep is necessary in for correctness, so that a user (or a script!)
> won't be surprised by nothing happening. If FAT has a 2-second time
> granulation, and we only sleep for a maximum of 1 second, then that's
> obviously a bug in our code.
That's exactly what I wanted to indicate
-> we're all on the same track.
Whether you call it "data loss" or only "correctness bug".
"Data loss" is a fuzzy wording; some days ago our 300 MB (no logs)
/ 1800 revisions repository got corrupted due do Berkeley 4.1,
and we couldn't restore all revisions after the last backup,
so we really lost data; (Its a different topic, but maybe it is
a good idea that Subversion rejects compiling with <4.2,
plus giving more hints in the FAQ about how exactly compiling
Apache with 4.2. We didn't manage it even after investing
a lot of time into that.)
This is also no Subversion "data loss" in the strict sense,
because it is our own fault using bdb 4.1, similar to C.A.T.Magic's
sample where it's the user's own fault that he deleted his wc data.
But someone who lost data in such ways does not care about how
you call it -> its a good idea to try to avoid all kind of possibilities
how you can loose data directly or indirectly - whether you call
it "data loss" or not; in practise every "incorrectness" or
installation hurdle can be indirectly responsible for loosing
data and.
But I also understand that the Subversion team wants to avoid
that people erraneous think that Subversion itself may delete data.
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 28 18:02:55 2004