| RE: [stellation-res] Timing: The Solution |
On Sun, 2002-09-15 at 21:50, Jonathan Gossage wrote: > > > > >-----Original Message----- > > >From: stellation-res-admin@xxxxxxxxxxxxxxx > > >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Dave Shields > > >Sent: September 15, 2002 4:20 PM > > >To: stellation-res@xxxxxxxxxxxxxxx > > >Subject: Re: [stellation-res] Timing: The Solution > > > > > > > > >On Sun, Sep 15, 2002 at 11:10:50AM -0400, Jonathan Gossage wrote: > > >> > > >> > > >> There is a method that will deal with this scenario as well as > > >the previous > > >> one. If you force all files written to the workspace to have > > >timestamps 2 > > >> seconds earlier than the current time then I think you will avoid the > > >> scenarios presented above. > > > > > >I am wary of forcing the timestamps to be wrong. Also, why just > > >two seconds? > > The first round-down covers the fact that Unix systems always round down to > the lower bound. > The second second ensures that the checkin time and time stamp will always > be be less than any update that takes place during the checkin second but > after the actual checkin will always have a different time stamp. > > I agree with you that this is ugly but it will cover those scenarios. > > >> > > >> However there is another scenario that is a real killer. > > >Consider a PC with > > >> a system clock that drifts forward in time one second per > > >hour. Consider > > >> also that this system updates its time each hour from a time > > >server. The > > >> result will be that once an hour approximately the local clock > > >will be set > > >> back by one second. This gap presents an opportunity for an update > > >> immediately following a checkin to get a back-dated time stamp that can > > >> cause the update to be missed. > > >> > > >> I have only presented two scenarios here, but I believe > > >thatthere are other > > >> possible ones. While the window of opportunity for failure is > > >quite small, > > >> it is real and if we want to deliver a robust product I do not > > >think that we > > >> should rely on a mechanism which is out of our control and > > >which can lead to > > >> missed checkins > > >> > > >I agree there is problem, but it's hard to see how we can > > >anticipate all scenarios. > > > > The problem really is that timestamp recording within a given second is not > deterministic and can be affected by many factors. If you read some of the > Team related posts on Eclipse you an see situations that seem to be rooted > in this problem. The problem is that while, overall, the number of actual > occurences will be very low, in particular scenarios such as the time server > one I presented the probability of an error in that particular environment > becomes much higher. I personally think that if you are to use timestamps as > a discriminant, youwill have to accept the certainity of some number of > errors which are likely to be very low in most scenarios but which can > become unacceptablly high in special cases. The issue than becomes one of > engineering trade-offs. Do we accept the certainty of a very small number of > errors in the vast majority of cases as the prce for a significantly more > efficient change detection scheme. Personally for a product like Stellation > where the integrity of source code is so important I would prefer the > conservative solution I don't think it's reasonable for *every* use to have to pay a significant performance cost to work around a problem that will only affect a small number of eccentric environments. I'm willing to go along with an option to always do signature computation on all artifacts. But I don't want it to be a universally required behavior. For most people, the safety of timestamps is probably sufficient. -Mark -- Mark Craig Chu-Carroll, IBM T.J. Watson Research Center *** The Stellation project: Advanced SCM for Collaboration *** http://www.eclipse.org/stellation *** Work Email: mcc@xxxxxxxxxxxxxx ------- Personal Email: markcc@xxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part