"Jonathan Leffler" <jleffler@us.ibm.com> writes:
> Sorry about the way Lotus Notes handles embedded messages...
>
> Another question about 'svn up' - what prevents concurrent execution of
> 'svn up' on the same directory hierarchy? I tried:
>
> svn up & sleep 1 && svn up
>
> I didn't get an error about "already in use" (at least, not explicitly); I
> got:
>
> subversion/libsvn_wc/adm_files.c:555
> apr_error: #17, src_err 0 : <File exists>
> ./.svn/tmp/entries
That's odd. Updates and commits *do* drop lockfiles into each .svn/
area, and do exactly what you're talking about below.
So I'm curious why that error isn't about an existing lockfile...
>
> What about concurrent runs of update and commit? I fully accept that the
> working areas are primarily intended for a single-user (the repository is
> where the multi-tasking concurrency is a permanent issue), but do you need
> to enforce some sort of isolation?
>
> If you don't have (plans for) a mechanism in place yet, then maybe you
> apply a local lock at each directory in the hierarchy as you are working,
> maintaining a chain of locks from the top of the work area to the current
> directory. Then, if you started an update in ./abc/def/ghi and another in
> ./abc, then the top one would eventually run across the lock in
> ./abc/def/ghi and would know that it should ...do something... maybe wait
> for the lock to be released, or stop. If you wait, you have to worry about
> termination. If you wait with a timeout, you have to worry about large
> directories and slow networks (vs small directories and fast networks --
> different timeouts would be applicable). If you don't wait, you have to
> worry about rolling back what you've already done.
>
> --
> Jonathan Leffler (jleffler@us.ibm.com)
> STSM, Informix Database Engineering, IBM Data Management Solutions
> 4100 Bohannon Drive, Menlo Park, CA 94025
> Tel: +1 650-926-6921 Tie-Line: 630-6921
> "I don't suffer from insanity; I enjoy every minute of it!"
>
>
>
> Ben
> Collins-Sussman To: Jonathan Leffler/Menlo Park/IBM@IBMUS
> <sussman@collab.n cc: SVN Dev List <dev@subversion.tigris.org>, users@subversion.tigris.org
> et> Subject: Re: Subversion 0.13.0 [Pre-Alpha] released - a report on successes and
> Sent by: problems
> sussman@collab.ne
> t
>
>
> 06/19/02 01:18 PM
>
>
>
>
>
>
> "Jonathan Leffler" <jleffler@us.ibm.com> writes:
>
> > OK - svn cleanup did the trick. The residual question is "should I
> > have had to do that", to which I don't know the answer but it
> > doesn't feel quite right if that is necessary just because of an
> > interrupt.
>
> Yes, that's a good philosophical question. :-)
>
> In theory, 'svn up' could start out by running 'svn cleanup'
> internally... searching for any locks or logs, just like a journaling
> filesystem does when you boot it up.
>
> I think the reason we're not doing that (yet) is that we want to know
> when a working copy gets into a cleanuppable state. In other words,
> it helps developers find bugs, at a convenience cost to users. Maybe
> we should change this policy at some point...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 20 00:14:56 2002