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

Apologies - I didn't want to screw up my working copy, and didn't
appreciate that the problem was different.

$ cd subversion-r2263
$ svn update
U ./build.conf
U ./subversion.dsw
U ./build/buildcheck.sh
U ./build/gen_base.py
U ./subversion/include/svn_fs.h
U ./subversion/include/svn_sorts.h
U ./subversion/include/svn_client.h
^C
$ svn update

subversion/libsvn_wc/lock.c:47
svn_error: #21040 : <Attempted to lock an already-locked dir>
  working copy locked: ./subversion/include
$

I have now screwed it up for you...is there a way to fix this on my working
copy, or do I have to checkout from scratch?

--
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 11:41 AM                                                                                                
                                                                                                                                       
                                                                                                                                       
"Jonathan Leffler" <jleffler@us.ibm.com> writes:
> Reproduction, using svn r2263 (which is what I managed to get to build
and
> work - I also have r1868 and r2033 kicking around at this instant, though
> they are likely to go very shortly).
>
> $ mkdir subverted
> $ cd subverted
> $ svn checkout http://svn.collab.net/repos/svn/trunk -d svn
> A svn/HACKING
> A svn/svn_private_config.hs
> A svn/BUGS
> A svn/README
> A svn/subversion.dsw
> A svn/svn_check.dsp
> ^C
> $ svn checkout http://svn.collab.net/repos/svn/trunk -d svn
Ah, you said in your last mail that 'update' was leaving your working
copy in a broken state, not 'checkout'.  :-)
Yes, we're well aware of this checkout bug.  See issue #730:
basically, a checkout isn't recoverable.  The problem is that our
.svn/ area, when being constructed for this first times, don't know
when they're incomplete.
>
> subversion/libsvn_wc/adm_files.c:1012
> svn_error: #21036 : <Obstructed update>
>   revision 2283 doesn't match existing revision 0 in 'svn'
> $
>
> I note that it is not clear from the error message which file(s) in the
> repository is(are) causing the checkout error.  That may well be because
> there are multiple files involved, of course.
>
> Apologies for missing the info in INSTALL/README - I'll leave WebDAV
alone
> for the time being and use just the local repository.
>
> If you need more configuration information, tell me what you want.
>
> --
> 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:
users@subversion.tigris.org, SVN Dev List <dev@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 10:38 AM
>
>
>
>
>
>
>
> Forwarding this to the dev list.  The 'users' list is barely used at
> all right now.
>
> "Jonathan Leffler" <jleffler@us.ibm.com> writes:
>
> > I'm not clear what format you want feedback on successful builds of
SVN,
> or
> > problems while building or using it, so here goes.
> >
> > I've managed to build and install the 0.12 and 0.13 versions of
> Subversion,
> > and get the latest builds afterwards,
> > running on Ultra Sparc, Solaris 7, GCC 3.1, etc.
> >
> > I've encountered a couple problems in using it.
> >
> > 1.  Interrupting things (svn update) seems to leave the system in an
> > incoherent state, so I cannot resume the 'svn update' operation later.
> > Workaround: delete the entire subversion directory and start over.
>
> Can you be more specific, or give a reproduction recipe?  This is
> something we're trying to fix.  'svn update' makes changes to the
> working copy using logged commands, much like a journaling filesystem.
> In theory, we use this approach so we can exactly avoid this problem.
> :-)
>
>
> > 2. I'm having a dickens of a job getting Apache 2.0.36 to work with
> 0.13.0,
> > so I've been unable to set up a local SVN repository, even for playing.
> > The problem appears to be in loading the mod_dav_svn.so module, and
> > probably is related to the symbols used in the APR and/or APR-UTIL code
> > which are in the version of APR used by SVN but not in the one used by
> > Apache 2.0.36.
> >
> > I'm planning to try Apache 2.0.39 in the hope that this will fix the
> > problems -- it will probably use the latest and greatest APR.
>
> Yes, by definition, the latest subversion only compiles against the
> HEAD versions of httpd and APR.  You cannot use 2.0.36, and might not
> even be able to use 2.0.39.  You need to check out httpd from CVS
> directly, just as our INSTALL instructions say to do.
>
> Once we hit Alpha, Beta, or 1.0, then we'll starting enforcing
> compatibilty with specific release-numbers of APR and httpd.  But for
> now, you need to treat all three projects as moving targets.
>
>
> > Am I missing something?  Is there a way to set up a local repository
> > without having to go via the web server?
>
> Yes, if you have Berkeley DB compiled into your client (via the
> libsvn_ra_local module), then you can access repositories directly
> with your svn client.  It's all in the README and INSTALL files.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org