Date: Fri, 09 Aug 1996 21:01:36 -0700 From: John Polstra <jdp@polstra.com> To: Terry Lambert <terry@lambert.org> Cc: faulkner@asgard.bga.com, current@FreeBSD.org Subject: Re: Praise for CVSup Message-ID: <199608100401.VAA24795@austin.polstra.com> In-Reply-To: Your message of "Fri, 09 Aug 1996 19:32:23 PDT." <199608100232.TAA19886@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608100401.VAA24795>