Hi Martin,
>Here I disagree a bit: I think the timestamps should remain in the
>Entries files, the checksums should be added.
>One reason is probably backward compatibility.
>Another reason is that I use WinCVS as a front end, which has the nice
>feature to show locally modified files with a red icon. Thus you can
>easyly find them. If this algorithm were to rely on checksums rather than
>on time stamps, there would be much more work for my hard disk, resulting
>in much more noise and much slower action when simply changing
>directories in WinCVS.
>Maybe the WinCVS developers could tell us their opinion about that?
I. I think that timestamp should stay right where it is.
II. I was doing some thinking about the 'red icons problem' as we know it.
Whenever I'll have more time I will try to reduce it this way or another :)
There are few options here. Generally speaking I think it would be good to
have multi-level checking. That is why I feel it nice to keep the time-stamp
mechanism since it is fast and most of time works fine. I think about simple
algorithm like:
OPTION_1
1. Check the time stamp. If different (might be modified) then
2. Check the checksum, if different then mark file as red (probably
modified).
OR
OPTION_2
1. Check the time stamp. If different (might be modified) then
2. Check the FILE SIZE, if different then mark file as red (probably
modified).
The checksum or file size should be stored on the client side, but not
necessary embedded with CVS. WinCvs could have it's own file in the CVS
directory we could have 'WinCvs' directory (../CVS/WinCvs/..), and WinCvs
can store the checksum (CRC or whatever works) in some file. Whenever file
is checket-out, or updated, or changed by any CVS command, checksum is
updated. Of course it might be better to have such mechanism in CVS itself,
but in fact it might not be necessary. From my observation this problem
seems to be more important to the WinCvs users than others, simply because
they can see abovemention 'red icons'. Thus it might be right that WinCvs
solves the problem internally.
BTW: Please note that if the file is really modified then it probably will
have different size (perhaps more than 90% cases). And to get the file size
is much faster than CRC etc., possible same or fater than the timestamp.
Because the checksum or file size are calculated on the client side by
WinCvs, there are no problems with CR/LF.
Any comments?
BR,
Jerzy
The first thing they don't teach you at school: "Never say never".
All the issues not related to the list please send to me in private, thanks.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
