On 17 Oct 2001 12:01:11 -0500 Ben Collins-Sussman <sussman@collab.net> wrote:
BC>
BC> Tony, I'm cc'ing this back to the dev list. Everyone could benefit
BC> from this discussion. :-)
Oops, sorry about that I didn't pay attention to the "To:" address, it
should have been the list.
BC>
BC>
BC> "Tony Parent" <tparent@amcc.com> writes:
BC>
BC> > > Can you send us a documentation patch? Tell us where this critical
BC> > > step should have been mentioned? :-)
[...]
BC>
BC> > ------------
BC> > That being said, I still can't import via the web setup
BC> >
BC> > svn import http://fdc005.amcc.com:8080/svn/repos test
BC> >
BC> > svn_error: #21073 : <RA layer's server request failed>
BC> > The OPTIONS request returned invalid XML in the response: Unknown
BC> XML
BC> > element `options-response (in DAV:)'. (/svn/repos)
BC>
BC> Not sure what the problem is here. 90% of the time, when I've seen
BC> this error, it's because the Apache process dosen't have permission to
BC> modify the db files in the repository.
BC>
BC> On our servers, we often create an 'svn' user who owns the repo, and
BC> we tell Apache to run as that user.
But the apache server is running as me! Just to check, I did a
"chmod -R a+w" on the repository directory and tried again, but got the
same error. Is there anything else that needs to be setup in the httpd.conf
file to allow for writes to this dir?
BC> > but then when I try to check it back out, the svn client hangs and I
BC> > get an error in my error.log file from apache:
BC> >
BC> > svn co http://fdc005.amcc.com:8080/svn/repos/test (hangs)
BC> >
BC> > error log:
BC> > [Wed Oct 17 08:48:53 2001] [error] [client 10.101.101.32] Could not
BC> fetch
BC> > resource information. [500, #0]
BC> > [Wed Oct 17 08:48:53 2001] [error] [client 10.101.101.32] could not
BC> > determine resource kind [500, #21048]
BC> > [Wed Oct 17 08:48:53 2001] [error] [client 10.101.101.32] file not
BC> found:
BC> > filesystem `/scratch/tparent/svn/repository/db', revision `1', path
BC> > `/test' [500, #21048]
BC>
BC> Right. Because your import put the *contents* of 'test' into the root
BC> of the repository. There is no /test in the repository, as Apache
BC> said.
BC>
BC> If you wanted to create a 'test' subdirectory right below the
BC> repository's root, you should have used 3 arguments to import:
BC>
BC> % svn help import
BC> import: Import a file or tree into the repository.
BC> usage: import REPOS_URL [PATH] [NEW_ENTRY_IN_REPOS]
BC>
BC> % svn import file:///scratch/tparent/svn/repository test test
I did see that, but didn't know if it meant a t/f thing or name or what. I
guess I could have read the code, but it was easier to complain. :-)
BC>
BC>
BC> > Anyway, I then tried
BC> >
BC> > svn co http://fdc005.amcc.com:8080/svn/repos
BC> >
BC> > svn_error: #21073 : <RA layer's server request failed>
BC> > The OPTIONS request returned invalid XML in the response: Unknown
BC> XML
BC> > element `options-response (in DAV:)'. (/svn/repos)
BC>
BC> Probably permissions again.
Nope. I opened up permissions on the repository.
[...] ("See above" errors removed)
BC> > An other thing. If I create the test "repository" and import my test
BC> > directory into it, then try to check out that repository I get:
BC> >
BC> > % svnadmin create /scratch/tparent/svn/repository/test
BC> > % svn import file:///scratch/tparent/svn/repository/test ./test
BC> > Adding ./testme
BC> > Adding ./test_subdir
BC> > Adding ./test_subdir/subtest
BC> > Commit succeeded.
BC> > % cd test2
BC> > % svn co file:///scratch/tparent/svn/repository/test
BC> >
BC> > svn_error: #21017 : <Obstructed update>
BC> > Can't add 'testme':
BC> > object of same name already exists in 'test'
BC>
BC> In this example, you imported the contents of your local 'test' dir
BC> into the root of the repository.
BC>
BC> Then you checked out a URL, and didn't follow with a -d switch; thus
BC> the client decides to name your working copy whatever the basename of
BC> the URL is. In this case, 'test'.
BC>
BC> But wait, you already have a directory in front of you called 'test'.
BC> The client tries to fill in this directory with a .svn/ dir and tries
BC> to add files to it, but of course there are already files in there by
BC> the same name -- hence the obstructed checkout.
Hmmm, but I cd'ed to a different directory intentionally so I wouldn't try
to overwrite the initial test directory. Once I used the third arg to
import this problem went away, so maybe it wasn't test that it was worried
about, but ".". =8-(
BC>
BC> Morals of the story:
BC>
BC> * use a -third- argument to import to create subdir entries in the
BC> repository.
BC>
BC> * use a -d switch to checkout to name your working copy.
BC>
BC> Of course, this is all happening to you because our client app isn't
BC> well documented yet, either internally or externally. (Fitz is
BC> working on that, right?) You're a brave soul, Tony. :-)
This is to be expected on such a new project. I'm just happy you are so
willing to help, and not just saying, "Yeah Yeah, RTFM when we get one..."
I'm just trying to keep abreast of what is going on out there...
Speaking of which, have you looked into "dvs" at all? It uses a little
different concept for the back-end server, but allows a client to have a
working copy of something that is actually a composite of stuff stored on
different servers. (So things the local "editors" are working on are stored
on a local server, but the entire project is a collection of server
repositories.) I think you are handling this with replication of the
repositories to other sites. (I think I read that somewhere in the docs
that do exist.)
I only say this as something that might be nice to look at to see how
others are approaching the problem of distributed configuration
management. DVS and it's server NUCM are research projects from SERL.
(http://www.cs.colorado.edu/serl)
--
===================================================================
== Tony Parent AMCC FDC ==
== Design Automation Engineer tparent@amcc.com ==
== 4715 Innovation Drive Phone: (970) 267-5120 ==
== Fort Collins, CO 80525 FAX: (970) 267-5180 ==
===================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:44 2006