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

Re: Fixing time stamps

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-10-30 14:53:04 CET

"Sander Striker" <striker@apache.org> writes:

> What about status? If it detects a bogus timestamp, can it at that
> point take out a write lock and attempt to repair?

It could, but it doesn't at present. I don't really like the idea of
a read-only operation like status attempting to become
read-write.

On the implementaion front, it's probably not feasible to permanently
convert an existing read lock into a write lock, so it might have to
attempt to take and release a temporary write lock. That could be a
real performance killer if there are a large number of broken
timestamps, it's much better to do the repairs in an operation that
starts out with a write lock. What if anything should happen if it
failed to get a write lock?

>> There is no way, at present, for the user to find out that Subversion
>> has detected the problem.
>
> Failing the above, would an extra notice in the status output help?
> 'T' for bogus timestamp? This would then prompt the user to run
> svn cleanup (while not requiring it). Ofcourse this could be unclear...
> and given the new status output, potentially overkill.

That's better from an implementaion/performance point of view, but I'm
not convinced that we really want it in the default status output. We
come back to my suggestion 1) an additional option to status, one that
causes it to take out a write lock, and to report and repair broken
timestamps.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 30 14:53:51 2003

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.