On Thu, Feb 13, 2003 at 12:39:51PM +0000, Philip Martin wrote:
>
> 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.
These are valid concerns. Extra work is extra work.
> 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?
Not in the grand scheme of war and hunger and stuff, but in terms
of command-line snappyness the difference between a .5s update
and a 1.1s update is noticeable.
> 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.
Sure, we could, for example, have a "--no-sleep" option.
> 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.
While this is true, I think that delay (and thus the associated savings)
is probably quite small. That doesn't mean it isn't worth doing, though.
>
> 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.
>
Yes, that would certainly be interesting. Something like RCS's "co -M".
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 13 21:12:45 2003