From owner-freebsd-current Sun Aug 11 10:28:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA27035 for current-outgoing; Sun, 11 Aug 1996 10:28:28 -0700 (PDT) Received: from utgard.bga.com (utgard.bga.com [205.238.129.45]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA27030 for ; Sun, 11 Aug 1996 10:28:24 -0700 (PDT) Received: (from faulkner@localhost) by utgard.bga.com (8.7.5/8.7.3) id MAA00442; Sun, 11 Aug 1996 12:28:17 -0500 (CDT) Message-Id: <199608111728.MAA00442@utgard.bga.com> Subject: Re: Praise for CVSup To: jdp@polstra.com (John Polstra) Date: Sun, 11 Aug 1996 12:28:17 -0459 (CDT) From: "Boyd R. Faulkner" Cc: current@FreeBSD.org In-Reply-To: <199608100159.SAA24389@austin.polstra.com> from "John Polstra" at Aug 9, 96 06:59:42 pm X-Mailer: ELM [version 2.4 PL25 ME8b] Content-Type: text Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk 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 _____________________________________________________________________________