You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by mark benedetto king <mb...@boredom.org> on 2003/02/13 04:02:51 UTC
RFC: timestamps/sleep
Greg Hudson and I discussed the following idea on IRC today:
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?
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: timestamps/sleep
Posted by Michael Price <mp...@atl.lmco.com>.
Greg Hudson writes:
> On Thu, 2003-02-13 at 07:39, Philip Martin wrote:
> > I think setting the timestamps will involve additional writes to the
> > disk.
>
> You're right, though it depends on the filesystem.
Well, ignoring network filesystems for the moment, its only not a write
if the filesystem in question does asynchronous meta-data
writes. However, if you are writing meta-data asynchronously then you are
almost certainly writing everything asynchronously which no one running
a "real" server (i.e. people with real data they care about) is ever
going to do. So yes, it involves additional writes.
Whether or not that's a big deal is debatable. I don't imagine it would
be a problem but then again, I have a weird imagination.
> This is a totally different feature; the fact that both would be using
> utimes() doesn't make them terribly related. And I would say the time
> of the last commit isn't the right answer; the right answer is a
> timestamp property set on the file (which we don't current set). That
> way you could a import a collection of files with this property set on
> each file, and a checkout would have the same timestamps--a property
> many build systems want to ensure.
That would be a nice feature.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: timestamps/sleep
Posted by Greg Hudson <gh...@MIT.EDU>.
(Didn't notice this message was in the thread before I sent my last
response.)
On Thu, 2003-02-13 at 07:39, Philip Martin wrote:
> I think setting the timestamps will involve additional writes to the
> disk.
You're right, though it depends on the filesystem.
> An alternative idea to reduce the sleep: track the most recent
> timestamp.
This is probably not much more complicated (it requires libsvn_wc to
update a timestamp variable each time it stores one in the entries file,
as opposed to my and Ben's idea where it would have to see a timestamp
variable each time) and will probably save the full second in most
cases.
So, if we do anything, this is probably the direction to go.
> 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 an operation?
This is a totally different feature; the fact that both would be using
utimes() doesn't make them terribly related. And I would say the time
of the last commit isn't the right answer; the right answer is a
timestamp property set on the file (which we don't current set). That
way you could a import a collection of files with this property set on
each file, and a checkout would have the same timestamps--a property
many build systems want to ensure.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: timestamps/sleep
Posted by Branko Čibej <br...@xbc.nu>.
mark benedetto king wrote:
>I think the timestamps would be changed on the files in .svn/tmp, which
>would then be moved into place with the correct timestamps. This would
>only happen for files that were actually merged.
>
>
You're assuming that a file keeps its timestamp when it moves. There's
no such guarantee.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: timestamps/sleep
Posted by mark benedetto king <mb...@boredom.org>.
On Thu, Feb 13, 2003 at 10:51:15AM -0600, Karl Fogel wrote:
> Philip Martin <ph...@codematters.co.uk> writes:
> > 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.
>
> Yes, very! If Subversion changes timestamps, many editors will notice
> and tell you that the file has changed on disk. Emacs will ask you if
> you want to reload... Very annoying, and likely to cause people to
> accidentally lose their buffer-local changes.
>
I think the timestamps would be changed on the files in .svn/tmp, which
would then be moved into place with the correct timestamps. This would
only happen for files that were actually merged.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: timestamps/sleep
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:
> 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.
Yes, very! If Subversion changes timestamps, many editors will notice
and tell you that the file has changed on disk. Emacs will ask you if
you want to reload... Very annoying, and likely to cause people to
accidentally lose their buffer-local changes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: timestamps/sleep
Posted by Michael Price <mp...@atl.lmco.com>.
mark benedetto king writes:
> On Thu, Feb 13, 2003 at 12:39:51PM +0000, Philip Martin wrote:
> > 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.
Random-odd-statistic:
If you perform an operation ending in a one second sleep every 30
minutes during an average workday then every year you end up sleeping
over 1 hour.
Now, for any real human this will be lost in the lunch and coffee break
noise but for the extremely anal its still a lost hour :)
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: timestamps/sleep
Posted by mark benedetto king <mb...@boredom.org>.
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
Re: RFC: timestamps/sleep
Posted by Philip Martin <ph...@codematters.co.uk>.
mark benedetto king <mb...@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
Re: RFC: timestamps/sleep
Posted by Branko Čibej <br...@xbc.nu>.
Garrett Rooney wrote:
> mark benedetto king wrote:
>
>> On Thu, Feb 13, 2003 at 07:31:29AM +0100, Branko ?ibej wrote:
>>
>>
>>> Yup. *Not* the startup time, please, as that assumes the client is a
>>> command-line app that gets run once for each command. Instead,
>>> libsvn_client could note the time each operation started; that would be
>>> friendly to GUI clients, svnshell.py and (the not-yet-implemented) "svn
>>> --shell".
>>>
>>>
>>
>>
>> How about adding a "now" field to the client context?
>> libsvn_client/libsvn_wc
>> wouldn't know anything about sleeping or retro-dating, they just know
>> "now",
>> and they make sure that files get created with dates of "now".
>>
>> It is up to the client to sleep if it wants to.
>>
>
> i'm not sure i like the idea of pushing this onto the client
> application. it seems like the kind of thing people are likely to
> screw up, and if we can do it once in the libraries and get it right
> then we're probably better off.
I agree. "now" probably should be in a baton somewhere, but the library
should be settng it, not the client app. Same for sleeping -- the (wc)
library should take care of that.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: timestamps/sleep
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
mark benedetto king wrote:
>On Thu, Feb 13, 2003 at 07:31:29AM +0100, Branko ?ibej wrote:
>
>
>>Yup. *Not* the startup time, please, as that assumes the client is a
>>command-line app that gets run once for each command. Instead,
>>libsvn_client could note the time each operation started; that would be
>>friendly to GUI clients, svnshell.py and (the not-yet-implemented) "svn
>>--shell".
>>
>>
>>
>
>How about adding a "now" field to the client context? libsvn_client/libsvn_wc
>wouldn't know anything about sleeping or retro-dating, they just know "now",
>and they make sure that files get created with dates of "now".
>
>It is up to the client to sleep if it wants to.
>
i'm not sure i like the idea of pushing this onto the client
application. it seems like the kind of thing people are likely to screw
up, and if we can do it once in the libraries and get it right then
we're probably better off.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: timestamps/sleep
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2003-02-13 at 08:21, mark benedetto king wrote:
> How about adding a "now" field to the client context? libsvn_client/libsvn_wc
> wouldn't know anything about sleeping or retro-dating, they just know "now",
> and they make sure that files get created with dates of "now".
>
> It is up to the client to sleep if it wants to.
I agree with Garrett; we should handle this all in libsvn_client.
(Which is where we currently handle sleeping as is.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: timestamps/sleep
Posted by mark benedetto king <mb...@boredom.org>.
On Thu, Feb 13, 2003 at 07:31:29AM +0100, Branko ?ibej wrote:
>
> Yup. *Not* the startup time, please, as that assumes the client is a
> command-line app that gets run once for each command. Instead,
> libsvn_client could note the time each operation started; that would be
> friendly to GUI clients, svnshell.py and (the not-yet-implemented) "svn
> --shell".
>
How about adding a "now" field to the client context? libsvn_client/libsvn_wc
wouldn't know anything about sleeping or retro-dating, they just know "now",
and they make sure that files get created with dates of "now".
It is up to the client to sleep if it wants to.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: timestamps/sleep
Posted by Branko Čibej <br...@xbc.nu>.
mark benedetto king wrote:
>Greg Hudson and I discussed the following idea on IRC today:
>
>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?
>
>
Yup. *Not* the startup time, please, as that assumes the client is a
command-line app that gets run once for each command. Instead,
libsvn_client could note the time each operation started; that would be
friendly to GUI clients, svnshell.py and (the not-yet-implemented) "svn
--shell".
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org