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>