RE: [stellation-res] Timing: The Solution

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> >-----Original Message-----
> >From: stellation-res-admin@xxxxxxxxxxxxxxx
> >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of David Shields
> >Sent: September 14, 2002 12:11 AM
> >To: stellation-res@xxxxxxxxxxxxxxx
> >Subject: RE: [stellation-res] Timing: The Solution
> >
> >
> >
> >Jonathan (and anyone else interested),
> >
> >Please feel free to do what you think best, and you shouldn't feel
> >constrained by the quick hack I put together, which was done in part just
> >to show by example how to add an option, new subcommand, etc.
> >
> >dave
> >

I have had a good look at this problem. Ibelieve that the fix you have
implemented will work for the specific scenario that you presented i.e.
modify file
checkin
mo0dify same file in the same second as the checkin

The problem is that there are other scenarios where this fix will not help.
Consider the situation where you checkin a number of files. At the same time
some external script is running asynchronously and it changes one of the
files during the same second as the checkin takes place but after the
timestamp has been determined. In this case waitng until the next second to
proceed will not prevent the asynchronous process from updating the file but
leaving an apparently unchanged timestamp.

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.

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

Regards

Jonathan

Personal Email
jgossage@xxxxxxxx

Business Email
jonathan@xxxxxxxxxxxxxx