kfogel@collab.net writes:
> > I think we would still need a way to prevent svn_client_status from
> > taking write locks. Consider a long running GUI that periodically
> > makes calls to svn_client_status to update it's view of the world. If
> > the svn_client_status calls take write locks then that would mean that
> > a command line commit would occasionally fail because it failed to get
> > a write lock.
>
> Good point, I hadn't thought of that. But still, if
>
> 1. Subversion operations are regularly fixing timestamps, and
> 2. otherwise-read-only operations only take out write locks when
> the absolutely need to fix a timestamp(s), and
> 3. Subversion is careful to only take out the write lock once per
> directory, and hold it only for as long as necessary to make all
> the fixes in that directory
>
> ...then any given run of GUI status (or whatever) will not have many
> write locks, and will not interfere with other things.
We went out of our way to get apr_temp_dir_get() into APR so that we
could avoid assuming that we have write access to working copies for
read-only operations. Can we please not invalidate that work? There
is absolutely no reason why 'svn cat', 'svn log', 'svn status', 'svn
propget', 'svn proplist', 'svn diff', 'svn diff', etc. should
*require* write access to disk, even for such a noble cause as
timestamp touch-up.
That said, I'm not opposed to some such read-only operations trying to
fix timestamps as they go along, as long as they promise to never
return an error if they are barred from doing so as a result of
permissions problems.
Finally, while 'svn status' would seem like the perfect place to do
this kind of timestamp patch-up, I strongly believe that it is a
special subcommand that should never write to a working copy, and
instead focus its efforts strictly on read-only reporting.
My thoughts.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 30 21:30:59 2003