[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: trivial yet very serious bug, suggestions welcome

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-10-28 01:56:18 CEST

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.


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
Received on Sat Oct 21 14:36:46 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.