[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion 0.13.0 [Pre-Alpha] released - a report on successes and problems

From: Jonathan Leffler <jleffler_at_us.ibm.com>
Date: 2002-06-20 00:03:11 CEST

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

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:01:20 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.