Re: repair timestamps of unchanged files

Branko ÄŒibej <brane@xbc.nu> writes:

> But I said before that if we allow non-modifying operations such as
> diff during a modifying operation such as update or commit, then the
> whole thing is broken anyway. We can't allow multiple readers /and/ a
> single writer to access the WC, only multiple readers /or/ a single
> writer. What I'm saying is that the multiple-reader idea isn't really
> useful anyway.

I'm not sure exactly what you are proposing. Do you want readers to
lock the WC? If so, won't that cause a performance problem? If not,
how else do you prevent multiple readers?

What about a WC to which I don't have write access?

Are you proposing that serialisation is the users' responsibility? If
so, how do I use my Subversion aware editor when my Subversion aware
file browser periodically scans the WC?

If readers don't lock the WC then I don't see what serialisation
gains. When a read-only operation determines that it needs write
access to repair a timestamp I'd be very unhappy if it simply assumed
that serialisation has been enforced. At present the algorithm to
upgrade a read-only lock to a write lock would be something like:

   if working copy version != SVN_WC__VERSION:
     cannot upgrade to write lock
   else if cannot get physical lock:
     cannot upgrade to write lock
   else if entries read from file != entries in memory:
     drop physical lock
     cannot upgrade to write lock
   else
     successful upgrade to write lock

If we have "user enforced" serialisation where readers don't take a
physical lock then I think we would still need to use the same
algorithm.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org