> This 'time repairing' only happens when you run 'svn cleanup' which -
> given the nature of the command - most people don't use on non-broken
> working copies. Maybe it happens with other write-requiring operations
> too, but definitely not with 'svn status' which is a read only
> operation (and no, we can't make it upgrade its lock to write: 2 'svn
> status' commands may stumble over each other)...
Hmm, I see. What a shame. Is the mtime of the text-base file currently
used for anything? Otherwise we could misappropriate it: Instead of (or
in addition to) storing the mtime in the admin area, simply touch the
text-base when a full comparison returns negativ. When checking compare
the mtime of text-base and WC file. If the latter is newer to enother
full comparison. The advantage here would be that a touch is (ought to
be?!) an atomic operation or at least implementable in such a way that
it can be done without aquiring write lock. That way status can maintain
the mtime records and the WC wouldn't "age".
> Heh, well, I do understand your point, and you'd do it another way if
> there were no .svn directory, but you really shouldn't be accessing
> the content of the .svn directory at all. Just a warning...
I know, but hey it's there and while it's there it's the most convenient
way of doing what we wanted. We never write to it though.
> Adding options is a programmers way to take no decisions. I'd rather
> not resort to that :-)
But some decisions cannot be made at compile time, after all that's why
they invented the if-keyword. ;-)
Seb
Received on Thu Nov 9 23:27:58 2006