mark benedetto king <mbk@boredom.org> writes:
> What if svn were to note its startup time, set all created files to
> that time, and then, at exit time, if any files were modified, wait
> until the time has changed from that time (which it probably will have
> already)?
>
> 1.) There is no lie. svn *could have* updated that file then.
> Well, maybe that's a small lie. :-)
> 2.) There is likely no/little sleep required, and certainly no more than
> in the existing scheme.
>
> Are we missing something?
I think setting the timestamps will involve additional writes to the
disk. If so these are likely to be undesirable as the additional IO
will slow down the operation. While this will be offset by avoiding
the sleep, it will make the operation more expensive to the system as
a whole. It will penalise you if you are trying to do anything else
on the disk while running the Subversion command, it will penalise
multiuser systems, network filesystems, etc. In general it would be
"selfish" of Subversion to operate this way if it could avoid it.
A question that needs to be considered is who cares about the sleep
time? Obviously it affects the regression tests, but I don't think we
should be designing the system purely for that. The effect on someone
using the command line client is fairly small, it would be even
smaller if we fixed update so that it didn't sleep if there are no
changes. Do they care about a one second sleep after a thirty second
checkout? They possibly care more about a one second sleep after a
four second update, but are either of these a real problem?
It has a bigger effect on someone using the programmers' API, but then
it's possible that the API should offer an interface that doesn't ever
sleep, but instead returns some indication that the timestamp
integrity needs to be considered.
An alternative idea to reduce the sleep: track the most recent
timestamp. The timestamps that matter are those stored in the entries
file. These are generally modified by running a log file, so the
procedure for updating an "interesting" file is
- write interesting file in .svn/tmp area
- rename interesting file
- write entries file into .svn/tmp
- rename entries file
- remove log file
- remove lock file
- sleep
There is a delay between the the first step, which determines the
timestamp, and the sleep. If this delay could be determined it could
be used to reduce the sleep, for large working copies with dozens of
locks it may be enough to eliminate the sleep altogether. Determining
the delay would involve tracking the most recent timestamp, and since
we put timestamps into the entries file it should be possible to do
this without increasing disk IO.
Finally, if we do implement setting the timestamp then perhaps we
should consider a mode that sets the timestamp to the time of the
commit rather than the start of the operation? This probably should
not be default way to operate, but it would be interesting to have
Subversion work that way.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 13 13:40:51 2003