Date: Sun, 11 Aug 1996 12:28:17 -0459 (CDT) From: "Boyd R. Faulkner" <faulkner@asgard.bga.com> To: jdp@polstra.com (John Polstra) Cc: current@FreeBSD.org Subject: Re: Praise for CVSup Message-ID: <199608111728.MAA00442@utgard.bga.com> In-Reply-To: <199608100159.SAA24389@austin.polstra.com> from "John Polstra" at Aug 9, 96 06:59:42 pm
next in thread | previous in thread | raw e-mail | index | archive | help
According to John Polstra: > > > > 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. > > Well ... yes and no. It depends on the situation. In general, CVSup > does _not_ ID the files via MD5 checksums. It compares the time stamps > between the client and the server, and if they are identical, it assumes > that the files are identical too. In that case, it doesn't examine the > files further. (There is an exception which, I conjecture, applies to > your particular case. I'll explain that in a minute.) > > 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. On the > client, it checksums each file. On the server, it parses each RCS > file, and checksums each revision on the selected branch, from most > recent to least recent. This is the worst situation, in terms of > server load, but it's not as bad as it sounds. First, it's computing > the checksums on the fly as it generates revisions -- not doing > some gross thing like calling "co" to emit them to temporary files. > So its main activity involves crunching through a memory-mapped > RCS file, computing the checksums as it goes. Second, if the client > already has files, they're probably fairly recent. So the server > won't have to checksum very many revisions before it finds the > right one. Third, this situation only happens the first time a > given client uses CVSup in checkout mode. After that, the so-called > "list files" remember which revisions the client possesses. So you can force the issue by deleting the info files. This is doubtless what happened. Perhaps I could have done the same thing by blowing away the sup info files. I still like this one better. Thanks again, Boyd -- _____________________________________________________________________________ Boyd Faulkner "The fates lead him who will; faulkner@asgard.bga.com Him who won't, they drag." http://asgard.bga.com/~faulkner Old Roman Saying -- Source: Joseph Campbell _____________________________________________________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608111728.MAA00442>