| Re: [stellation-res] Revised version of Jonathan Gossage's workspace audit |
On Wed, 2002-09-04 at 13:37, Dave Shields wrote:
> On Tue, Sep 03, 2002 at 07:53:24PM -0400, Jonathan Gossage wrote:
> >
> >
> > > >> 7. The call to the Unix utility "sleep" seems a bit heavy-weight when
> > > >> you can easily use the Java Object.Wait(time) calls. Incidentally
> > > >> Windows has the same problem with file modified time, so this should
> > > >> not be Unix specific anyway.
> > > >>
> > > >
> > > >TODO. I tried to do this but ran into problem so I left in old code
> > > >and commented-out the new code I had just added.
> >
> > The idiom I use is
> > try {
> > synchronized(this) {
> > wait(timeInMilliseconds);
> > }
> > }
> > catch (InterruptedException ex) {
> > }
> > The wait can be satisfied in one of three ways.
> > a) The time interval can expire.
> > b) Another thread invokes the notify method for this object.
> > c) Another thread interrupts this wait. In this case an Interrupted
> > exception will be thrown.
> >
>
> Thanks for the tip. I had forget to put in synchronized, and have just
> added your revised code to my current version.
>
> > > >> 12. The "getComment" method needs updated Javadoc with @param, @return
> > > >> and @throws specs.
> > > >>
> > > >> If you prompt for a comment in command line mode, you should tell the
> > > >> user how to end the comment. Many users have forgotten or do not know
> > > >> how to type an EOF from the keyboard. As a quick check I asked our
> > > >> Unix developers where I work and not one could remember how to do
> > > >> this. I couldn't either!
> > > >>
> > > >
> > > >TODO. It's control-D, though as I recall one can use stty to set this
> > > >character to some other value so you can't assume that control-D
> > > >will work.
> >
> > You can tell them that control-D is the character unless the machine has
> > been reconfigured. My point is that the number of people who use this on a
> > day-to-day basis is much smaller than it used to be and that a visual
> > reminder is friendly.
> >
>
> I agree we should put this in. I've left the TODO in as I haven't yet made
> the change.
>
> > > >> 36. The method "normalizeText" neds the Javadoc entry revised to
> > > >> reflect new implementation.
> > > >>
> > > >> I have serious doubts about the usefulness of this operation. It is
> > > >> costly and given that all internal operations are done on text
> > > >> artifacts where line termination characters have been removed during
> > > >> the construction process I don't see the benefit.
> > > >>
> > > >
> > > >It is costly, but it is needed. For example, I have encountered
> > > >unnormalized files in the Linux kernel, and several times after Jim
> > > >Wright has checked in code he created under Eclipse and forgot to put
> > > >in "normal" form.
> >
> > I think I must have a conceptual problem here. Could you explain why
> > un-normalized files represent a problem. I am probably missing an important
> > point.
> >
>
> This is discussed in the guide (search for 'normal'). I'll post a separate
> note on this shortly, as it's probably something we should also put in the
> FAQ as well.
>
> > > >
> > > >TODO. I converted Project signature to be md5 checksum this weekend.
> > > >I used MD5 only since I didn't want to run into any US export
> > > >regulations re cryptographic software, and a quick search via Google
> > > >indicated MD5 was NOT subject to any such restrictions.
> > > >It's easy to convert to SHA if it is not subject to any export
> > > >restrictions.
> >
> > There have been no export problems for a couple of years except to a very
> > small set of countries - Iraq, Iran, Libya, Cuba I think are the sensitive
> > ones. Incidentally we use SHA-1 in a product that is cryptography based and
> > that we ship world-wide.
> >
>
> I have converted artifact and project signatures from MD5 to SHA.
Incidentally, the comment I made the other day about the odds of the
hashcode being wrong was actually about SHA, not MD5. The odds of SHA
getting two the same hashcode for two closely related documents is in
the range of 1 in 10^60. The odds of a stray solar gamma triggering
a transient fault that flips a bit is in the range of 1 in 10^45 to 1 in
10^50. (I don't have a reference for this handy... It's based on a
comment in a lecture given by an expert on safe systems, who was
discussing the limits of safety.)
MD5 is still pretty good, but because of the smaller hashcode size, the
possibility of error is significantly more likely. (Although a lifetime
of checkins would still be very unlikely to yield a single error.)
-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