On Mon, 22 Nov 2004 23:01:45 +0000, Philip Martin
<philip@codematters.co.uk> wrote:
> Julian Foad <julianfoad@btopenworld.com> writes:
>
> > I was hoping there would be a better (more automatic and invisible)
> > way than any of these four options, like making read-only operations
> > (status, etc.) do the fix-up as and when they notice the discrepancy.
> > In fact, I think it was discussed way back
>
> http://svn.haxx.se/dev/archive-2003-10/1528.shtml
>
> > that they could attempt to
> > convert their read lock to a write lock on discovering the problem,
> > and repair it if the write lock was obtained, else leave it for
> > another time.
>
> I'm still uneasy about the idea. In addition to the problems
> mentioned in the old thread, "read locks" aren't really "locks" at
> all, so any such conversion would need to reread the entries file and
> it could have changed--a tricky thing to handle. Further, write locks
> are responsible for working copy format upgrades, to allow the entries
> file to be rewritten, and having "svn status" do such an upgrade is
> really unfriendly in my opinon, although I suppose we could do the
> read-to-write conversion only if the formats already match.
Would it be possible to use the timestamps in the text-base files as a
baseline, instead of data in the entries file? This way, one would
just need to touch the text-base files, avoiding (most) concurrancy
issues.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 23 00:23:57 2004