Date: Mon, 31 May 1999 10:56:07 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: Kris Kennaway <kkennawa@physics.adelaide.edu.au> Cc: current@freebsd.org Subject: Re: Announcing a new cvsup server - cvsup6.freebsd.org Message-ID: <XFMail.990531105607.jdp@polstra.com> In-Reply-To: <Pine.OSF.4.10.9905311419070.32616-100000@bragg>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote: > The solution I see here is for the cvsup mirrors to maintain > a timestamp of the last time they updated from freefall (for > multi-tiered mirrors, this value should be passed down the chain so > each of them knows the age of their files relative to the master > server) I've been down that road and was not able to come up with a workable solution. But if anybody can come up with a detailed algorithm for me, I'll welcome it with open arms. The basic problem is in the phrase "a timestamp of the last time they updated from freefall." There is no single timestamp that is representative of an update. Suppose I start an update at 15:00:00 UTC, and it finishes at 15:10:00. Every file updated came from a snapshot at some point of time in that range. In other words, CVSup can't take an instantaneous, coherent snapshot of the entire repository and give it to you. How could it, given that a tree walk alone over the repository takes a couple minutes? And that's just the easy case. Suppose that a mirror started an update, and then the network bogged down, and it didn't finish until hours later. Or suppose that it got partway through its update and then the connection was lost. In that case, some of its files would be current from within the range of the update, and some of them would still be the old versions from the previous run. Plus, a user might do an update of, say, cvs-all one day, and then just src-bin (a subset of cvs-all) a week later. Or he might use the "-i pattern" construct to update just a few files. Experience has shown that it's a bad idea to use the timestamps of the individual files, except for equality/inequality tests. You can't assume that the timestamps advance monotonically forward, because system administrators are human beings and they do dumb things like set their clocks wrong. Also, when a file has been removed on one side or the other, there's no timestamp to check. I think there might be an algorithm that would work, similar to what you proposed but a little bit more sophisticated. Each site (including clients) would need two timestamps T0 and T1, such that: * The site's most out-of-date file is at least as new as T0, and * The site's most up-to-date file is no newer than T1. Or something like that. ;-) John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.990531105607.jdp>