Re: trivial yet very serious bug, suggestions welcome

On Sat, Oct 27, 2001 at 06:47:54PM -0400, Greg Hudson wrote:
> > If we instead write a timestamp slightly in the future w.r.t. the
> > working file -- where "slightly" means "by an amount greater than
> > the greatest system granularity you ever heard of" -- then if we
> > ever saw a working file whose on-disk timestamp were closer to the
> > entry stamp than that amount, we'd know it had been modified. Uh,
> > right? :-)
>
> I don't see how this helps. If the file is modified before any system
> time passes at all, then we can't distinguish between that and the
> file not being modified.

Right. The suggestion just moves the time point, but doesn't really solve
the underlying issue.

> Waiting 1s after a checkout or update is one solution; that's what CVS
> seems to do (it checks whether the 1s has already elapsed since the
> "last_register_time" and does a sleep(1) if not; that check might be
> overkill for us since we can't use global variables).

This is very cool. And through the batons, we can definitely track a single
spot to record the last time seen.

> Touching the
> checked out files so that their last modified time is 1s in the past
> is another solution.

You would then have a bunch of false hits, need to checksum the files, and
then update the timestamps to avoid future false hits. I like the delay idea
much better.

> Remember that you have to worry about the same problem after an update
> or commit.

Good point.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org