Mitch Davis writes:
>
> My suggestion is, instead of storing the timestamp
> in CVS/Entries, the CVS client stores the MD5 of
> the file. And the up-to-date check performs an
> MD5 of the file. If they don't match, the CVS
> client knows beyond all doubt that the file has
> changed, and can contact the CVS server.
The problem is the severity of being wrong. If CVS thinks the file has
changed when it really hasn't, the worst thing that can happen is you
waste some time sending the file to the server when you don't really
need to. If CVS thinks that the file hasn't changed when it really has,
the worst thing that can happen is that you lose changes. I don't know
about you, but the latter sounds a whole lot more serious to me than the
former does.
Using timestamps can cause the first kind of error, but it can't (in
theory) cause the second kind -- it is simply not possible to modify the
file without updating the timestamp. (There are types of filesystems
were it is possible, but CVS simply doesn't admit to their existance.
And, although it is possible to explicitly reset the timestamp after a
modification, so many things depend on timestamps being correct that no
one ever does it.)
Using checksums avoids the first kind of error at the expense of making
the second kind -- it is not only possible but necessary that many files
have the same checksum (otherwise you'd have one really great
compression method). I'd rather spend the extra time occasionally and
get correct results than get bad results really fast.
-Larry Jones
I suppose if I had two X chromosomes, I'd feel hostile too. -- Calvin
