| RE: [stellation-res] Timing: The Solution |
On Sun, 2002-09-15 at 15:10, Jonathan Gossage wrote: > > > > >-----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. I've got a somewhat obnoxious attitude towards this, but I think that the basic argument is valid. If you've got an asynchronous script randomly updating a *versioned* file in your SCM workspace, and you expect the SCM system to successfully version that file correctly, you deserve whatever you get. An SCM workspace is not just a random directory in your filesystem. It's a special space, that you have to treat specially if you expect things to work correctly. You use special commands to manipulate files inside of it ("svc mv" instead of "mv", etc.).There is no way that we can guarantee correctness if you don't recognize that you need to treat the workspace as a workspace. Doing an unpredictable asynch update to a file in the workspace is not treating the workspace correctly. If the file is being unpredictably updated, what is the meaning of versioning it? What's the correct behavior when it gets updated and the latest version in the repository conflicts? Discard the result of your automated update script? Merge generating conflicts? I just can't see how this makes sense, or how we can define *any* reasonable behaviors that won't generate surprises in this case. > 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. This strikes me as kind of ugly, but if it works, I have no great objection about it - provided we have at least a command line option to disable it and use the real accurate timestamp. > 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. This is almost the same answer as the last one... Stellation takes several seconds to run. I'd like to improve that, but I'll be shocked if we get the execution time of real checkins down to less than a second. (And if we do, we can revisit this issue, because if we've managed to address the performance issues that well, then universal signature computation might well be a very reasonable thing to do.) If checkin takes over a second, and the timestamp is rounded down to the nearest second, then the only way to get this kind of a problem is if you're modifying files *during* a checkin. And if you're doing that, you're doing something seriously wrong! > 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 Here's the counter-argument. SCM systems are the systems that programmers love to hate. They recognize the need to use them, but they're frequently considered an annoyance. As annoyance with the SCM system increases, the frequency of interaction with that system *decreases*, significantly. Stellation is already on the slow side. And to make Stellation work at its best, we expect programmers to interact with it *frequently*. Slowing the system down significantly is going to be a *major* issue. Requiring complete signature computation all the time is going to *dramatically* slow down the system on large projects. Obviously, mine isn't the only vote. But without some more compelling, realistic examples of where this is going to be a real problem, I'm going to be against universal signature computation. -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