Date: Fri, 9 Aug 1996 19:32:23 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jdp@polstra.com (John Polstra) Cc: faulkner@asgard.bga.com, current@FreeBSD.org Subject: Re: Praise for CVSup Message-ID: <199608100232.TAA19886@phaeton.artisoft.com> In-Reply-To: <199608100159.SAA24389@austin.polstra.com> from "John Polstra" at Aug 9, 96 06:59:59 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > CVSup does more file checking than sup does. You can end up with > > files with the right date and size but not the right contents and, > > while I may be wrong, sup will not detect this. Since CVSup uses > > MD5 (yes?) to ID the files, you are gurarnteed the correct contents. [ ... ] > The reason it doesn't compare MD5 checksums for every file on the client > and the server is that it would be too slow, too compute intensive, and > too disk intensive. No real-time network file update package could do > that, without bringing the server to its knees. It has to cull the > unchanged files from the list using just the information that it can get > from a call to stat(). [ ... ] > The exception is when you are using CVSup's checkout mode the very > first time. In that case, CVSup cannot ID your existing checked-out > files via the time stamps, because the time stamps of the checked-out > files are not the same as the time stamps of the corresponding RCS > files on the server machine. So it really has no choice. One operational difference is that the files on the local file system seem to get the server file system timestamp on them after a data transfer instead of a local modification time time stamp. Sup apparently is using the local time stamping implied by POSIX. The implication here is that if your local clock is skewed relative to the SUP server by more than the amount of time between the CVS time stamp and the SUP time local to the SUP server... then using SUP you could very well get screwed. I believe CVSup has the capability to screw you this way if you do local checkins, which would modify the time stamp to the local time. If you had a negative skew, even if CVSup were checking for equality instead of later than, then you could get screwed. The window there is teeny. If the CVSup looks for a "greater than" time stamp, and your modification in local time took place after the last modification in server time, and both you and the server side made modifications to the file, then you could also be really screwed (with a big window). I think it checks equality, doesn't it? In any case, that could explain the difference, and you could still have a race condition waiting to bite you on the butt. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608100232.TAA19886>