| Re: [stellation-res] Timing: The Problem |
Is this really a problem outside of extremely canned situations like the test scripts? Does anyone have a *real* scenario where they can modify a file, check it in, then modify after checkin, and have the same timestamp? -Mark On Fri, 2002-09-13 at 14:04, Dave Shields wrote: > Apologies in advance for the long note, but I think it raises a > problem that must be addressed. If you are interested in working on > the solution, please respond to the thread > > Timing: The Solution > > which I will start shortly. > > Your timely responses to my request to "Could someone please run this > program on Windows" showed we do indeed have a problem with time, > namely Java's File.lastModified() method does not always work as one > would expect > > The problem is not urgent, in that Eclipse does it right, as do the > other reported systems, except for IBM's JDK 1.3 on Linux RedHat 7.1 > (the version I am using), and at least one version of Windows (Rodolfo > Araya can provide the details). > > However, the problem is real. For example, Jonathan Gossage reported > that his company has encountered several-second variations in clock > time on various Unix systems. I originally ran into this problem when > I noted failures on some regression tests, only to discover that two > versions of a file that had changed were deemed to be the same since > they were changed in the 'same' second. > > We could address this solely by an addition to the documentation. > For example, > > If you are using Version 1.3 of IBM's JVM on RedHat 7.1, then > after every checkin or checkout, please say the following phrase > to yourself > > I wish IBM would fix the bug in File.lastModified > > and make *sure* you take at least one second to do so. > > But -- eager programmers all -- we probably want to change the code. > > Now I could do it myself, but I think it best that I don't. Here's > why. > > There is a more urgent problem -- this project will only succeed in > the long run if we can get more non-IBM people involved -- and I see > this file modification time problem as a good opportunity to do this, > as we have a problem that is not urgent, provides a good introduction > to the workspace code, and raises some interesting challenges. > > In brief, I'm going to leave it to the community to sort this out. > > I've just checked in a first cut in changes to the workspace -- involving > the classes Files, Checkin, Checkout, Configure, Files, Project, and > Svc -- that do the following: > > 1) add a new option 'svc-check-wait' that can be used to wait for the > clock to catch up after a checkin or checkout > > 2) add a new command 'svc configure client' that runs a variant of the > Time program I posted yesterday to determine is the 'svc-check-wait' > option is needed and installs an appropriate value in the current > .svcrc file. > > 3) add a a test in the computeSignature() loop in Project so that, if > 'svc-check-wait' has been specified with a value starting with '-', > then file modification time will be ignored, and *all* artifacts will > have their signature computed. This provides a starting point for > investigating the performance issues. Is is really important to get > the time right, or should we just compute all signatures all the time? > > I will post a followup note with the diff output showing my recent > changes. If you read the code, you will learn how to add a new > command, a new option, and how to affect execution of one of the most > critical loops of the workspace (signature computation). I expect > anyone working through this will find bugs, or ways to improve the > system, or both. Doing it right may involve changing guide, tutorial, > unit tests (which raises a problem in itself, as this problem only > shows up on some operating systems), and so forth. > > Though in rough form, the code works in that, if I run the standard > tests with the IBM 1.3 JVM on Linux, they fail, and now pass only > if I first do > svc config system > to set an appropriate wait value. > > The rest is up to you. I'm asking Florin and Ringo to coordinate any > source commits. I'll try to stay out of this as much as possible, > except to answer any queries about the workspace code. > > thanks, > dave > > -- > Dave Shields, IBM Research, shields@xxxxxxxxxxxxxx. > _______________________________________________ > stellation-res mailing list > stellation-res@xxxxxxxxxxxxxxx > http://dev.eclipse.org/mailman/listinfo/stellation-res > -- 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