[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: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2001-10-29 23:57:46 CET

Greg Hudson <ghudson@MIT.EDU> writes:
> > 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.

You're right, I dumb.

Thanks. :-)

> 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). Touching the
> checked out files so that their last modified time is 1s in the past
> is another solution.
> Remember that you have to worry about the same problem after an update
> or commit.

Yup. Will do some solution like the above; it won't be a huge
performance hit, since it only affects files that are being written
out anyway.

Have filed issue #542, targeted for Alpha.


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.