Tony, I'm cc'ing this back to the dev list. Everyone could benefit
from this discussion. :-)
"Tony Parent" <tparent@amcc.com> writes:
> > Can you send us a documentation patch? Tell us where this critical
> > step should have been mentioned? :-)
>
> You just did. :-) in "trunk/notes/dav_setup.txt" add one more bullet item
>
> 11. If the repository you defined in step 7 doesn't already exist, you
> will
> need to create it:
>
> % svnadmin create /absolute/path/to/repository
>
> Then you can import something into it, either locally, or over dav:
>
> % svn import file:///absolute/path/to/repository /some/local/dir
>
> % svn import http://foo.com/repos/path /some/local/dir
Great, I'll add this to dav_setup.txt instructions.
> ------------
> That being said, I still can't import via the web setup
>
> svn import http://fdc005.amcc.com:8080/svn/repos test
>
> svn_error: #21073 : <RA layer's server request failed>
> The OPTIONS request returned invalid XML in the response: Unknown XML
> element `options-response (in DAV:)'. (/svn/repos)
Not sure what the problem is here. 90% of the time, when I've seen
this error, it's because the Apache process dosen't have permission to
modify the db files in the repository.
On our servers, we often create an 'svn' user who owns the repo, and
we tell Apache to run as that user.
> Running:
> svn import file:///scratch/tparent/svn/repository test
>
> works...
...probably because you own the repository db files.
> but then when I try to check it back out, the svn client hangs and I
> get an error in my error.log file from apache:
>
> svn co http://fdc005.amcc.com:8080/svn/repos/test (hangs)
>
> error log:
> [Wed Oct 17 08:48:53 2001] [error] [client 10.101.101.32] Could not fetch
> resource information. [500, #0]
> [Wed Oct 17 08:48:53 2001] [error] [client 10.101.101.32] could not
> determine resource kind [500, #21048]
> [Wed Oct 17 08:48:53 2001] [error] [client 10.101.101.32] file not found:
> filesystem `/scratch/tparent/svn/repository/db', revision `1', path
> `/test' [500, #21048]
Right. Because your import put the *contents* of 'test' into the root
of the repository. There is no /test in the repository, as Apache said.
If you wanted to create a 'test' subdirectory right below the
repository's root, you should have used 3 arguments to import:
% svn help import
import: Import a file or tree into the repository.
usage: import REPOS_URL [PATH] [NEW_ENTRY_IN_REPOS]
% svn import file:///scratch/tparent/svn/repository test test
> Anyway, I then tried
>
> svn co http://fdc005.amcc.com:8080/svn/repos
>
> svn_error: #21073 : <RA layer's server request failed>
> The OPTIONS request returned invalid XML in the response: Unknown XML
> element `options-response (in DAV:)'. (/svn/repos)
Probably permissions again.
>
> OK, that didn't work...
>
> svn co file:///scratch/tparent/svn/repository/test
> + exec /scratch/tparent/gnu2/svn-bin/svn co
> file:///scratch/tparent/svn/repository/test
>
> svn_error: #21048 : <Filesystem has no such file>
> file not found: filesystem `/scratch/tparent/svn/repository/db',
> revision `1', path `/test'
>
> Nope...
/test doesn't exist, see above.
>
> svn co file:///scratch/tparent/svn/repository
> A repository/testme
> % ls -l
> total 4
> drwxrwxr-x 3 tparent fdcsup 4096 Oct 17 08:54 repository/
> % lsl repository/
> total 0
> -rw-rw-r-- 1 tparent fdcsup 0 Oct 17 08:54 testme
>
> Which is not right either. I should have had a directory called test with
> the file testme inside it.
See above.
>
> This looks like a "repository" is really a top level for a project, not a
> true repository where you can place several projects. If that is true, I
> would then have to have a different "repository" for each project I wanted
> to revision control. And from there I would need to edit my Apache setup
> file to add the new "repository" each time I wanted to add a new project.
Not true, see above. :-)
> An other thing. If I create the test "repository" and import my test
> directory into it, then try to check out that repository I get:
>
> % svnadmin create /scratch/tparent/svn/repository/test
> % svn import file:///scratch/tparent/svn/repository/test ./test
> Adding ./testme
> Adding ./test_subdir
> Adding ./test_subdir/subtest
> Commit succeeded.
> % cd test2
> % svn co file:///scratch/tparent/svn/repository/test
>
> svn_error: #21017 : <Obstructed update>
> Can't add 'testme':
> object of same name already exists in 'test'
In this example, you imported the contents of your local 'test' dir
into the root of the repository.
Then you checked out a URL, and didn't follow with a -d switch; thus
the client decides to name your working copy whatever the basename of
the URL is. In this case, 'test'.
But wait, you already have a directory in front of you called 'test'.
The client tries to fill in this directory with a .svn/ dir and tries
to add files to it, but of course there are already files in there by
the same name -- hence the obstructed checkout.
Morals of the story:
* use a -third- argument to import to create subdir entries in the
repository.
* use a -d switch to checkout to name your working copy.
Of course, this is all happening to you because our client app isn't
well documented yet, either internally or externally. (Fitz is
working on that, right?) You're a brave soul, Tony. :-)
---------------------------------------------------------------------
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