From owner-freebsd-current Fri Aug 9 21:03:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA00381 for current-outgoing; Fri, 9 Aug 1996 21:03:08 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA00376 for ; Fri, 9 Aug 1996 21:03:06 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.5/8.7.3) with ESMTP id VAA24795; Fri, 9 Aug 1996 21:01:37 -0700 (PDT) Message-Id: <199608100401.VAA24795@austin.polstra.com> To: Terry Lambert cc: faulkner@asgard.bga.com, current@FreeBSD.org Subject: Re: Praise for CVSup In-reply-to: Your message of "Fri, 09 Aug 1996 19:32:23 PDT." <199608100232.TAA19886@phaeton.artisoft.com> Date: Fri, 09 Aug 1996 21:01:36 -0700 From: John Polstra Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Terry wrote: > 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. I am a little hazy about what sup does, but it definitely seems to preserve the time stamps of the files it updates. I.e., it does a stat() on the server's version, and passes that time stamp to a utimes() call on the client side. Any possible client-server clock skew won't affect that. Where clock skew might be an issue for sup is in the "when.cvs" file. A single time stamp is stored there, representing the time when the last update for the collection occurred. They call it the "scan time", so I assume it is a time representing when the tree was examined. (The beginning of the scan? The end of the scan?) I looked into enough to know that the time stamp comes from the server's clock, but I don't know much more about it. > 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? Yes, it checks for equality, for exactly the reason you described. I have thought about comparing file sizes, too. (In fact, I'm still thinking about it.) That would give a large added degree of safety. The disadvantage is the extra bytes needed to send the size for each file. I measured it recently. For a normal src + ports CVS tree, about 520 Kbytes (before compression) are sent from the client to the server to convey the filenames plus their time stamps. When I sent the file sizes too, it changed to around 620 K. (N.B., this is before the gzip compression; that reduces both numbers by about 65%.) Now, it turns out that, typically, the time for a CVSup run is dominated by exactly this transfer of file names and modification times. Normally, very few files need to be updated; most of the time and most of the bytes are spent in discovering that this is the case. Interestingly though, when I experimentally added the file sizes to the protocol, it didn't seem to change the elapsed time for doing a typical run. The time to do the tree walk on the server apparently was a bit greater than the time to send the information across the wire. (It was close, though.) However, this was with a 56 Kbit frame relay link. I worried that it would in fact make a noticeable difference over a slower link. What I think I might do is make it an option. Then the user can decide how to trade off paranoia against speed. -- John