On Mar 25, 2006, at 22:46, Mauricio Culibrk wrote:
> svn ls http://url.to.svn/repos/groupX IS working...
>
> The real problem is that I would like to have the list of
> repositories available in TortoiseSVN when issuing the svn list on
> the "root" repository... otherwise there is no "nice" way to know
> what repositories are available....
>
> So, yes, the SVNListParentPath on is nice in a browser - this just
> lists the files in the "parent" folder...
>
> So, basically, the problem is the same - how to setup a FUNCTIONING
> <Location>/<Directory> setup in Apache without having to define the
> <Location> directive for each and every (new) repository under the
> "virtual root" repository???
Ah yes, I had forgotten that SVNListParentPath only works in a web
browser, not from a Subversion client like TortoiseSVN or the command
line client. I consider that a bug, or at least a missing feature,
but I can't find anything filed in the issue tracker (no results
searching for SVNListParentPath). I'd like to file a bug report for
this issue... Anyone object?
Quite frankly, my Apache crashes when I try to svn ls the root when
using SVNListParentPath (Apache 2.2.0, Subversion 1.3.0, Mac OS X
10.4.5 PPC) though that could be a separate problem.
$ svn ls http://www.example.com
svn: PROPFIND request failed on '/'
svn: PROPFIND of '/': Could not read status line: connection was
closed by server. (http://www.example.com)
[Sun Mar 26 00:57:58 2006] [notice] child pid 27961 exit signal Bus
error (10)
There's also the issue where SVNListParentPath doesn't work unless
the path in the <Location> directive ends with a slash, though I'm
not sure if that's really still an issue or not.
http://svn.haxx.se/dev/archive-2006-01/0421.shtml
There's also the one where the XML produced when using SVNIndexXSLT
doesn't tell you which repository it's for, though I guess that's
kind of this:
http://subversion.tigris.org/issues/show_bug.cgi?id=2480
> if I setup something like this
>
> <LocationMatch "^/repos$">
> SVNPath /mnt/svn/root
> </LocationMatch>
>
> <LocationMatch "^/repos/.+">
> SVNParentPath /mnt/svn/root (or /mnt/svn becaouse of links)
> </LocationMatch>
>
> or anything with regular expression or any other form of
> "wildchars" the mod_dav_svn is throwing errors as "not found"
> because uses EXACT STRING specified in Location/LocationMatch!
> For example:
>
> URL /repos/.+/repos/!svn/bc/20/PM: No such file or directory
I've also encountered that. Subversion doesn't like LocationMatch.
Last month someone wrote a patch to address this somewhat:
http://subversion.tigris.org/issues/show_bug.cgi?id=2510
I'm not sure if that patch will help in your case but you could try it.
Admittedly I don't know the Subversion code, but I don't understand
why this patch had to introduce a new configuration directive. Seems
to me like Subversion should just be able to figure it out on its own.
> So, the Apache setup should be such that there is no "special
> characters" in the Location directive.... ok, then I tried with
> Rewrite and Redirect to "separate" the requests for the "root"
> repository to get the "repository list" and access to the real
> repositories but... again... no fun! :(
On Mar 25, 2006, at 23:01, Mauricio Culibrk wrote:
> Doing the thing with redirects (redirectmatch, rewrite...) works
> within the web browser almost like the SVNListParentPath but NOT
> with svn...
>
> svn list http://url/repos/ gives request failed on "/repos" - 405
> Method not allowed but works with the repositories
>
> svn list http://url/repos/group1 shows the directories....
>
>
> Seems the svn client won't accept any redirects or such
> "instructions"...
Yes, I've also encountered that the Subversion client doesn't obey
redirects and even barfs at mod_rewrite attempts. I've given up on
trying to use such tricks with Subversion.
http://subversion.tigris.org/issues/show_bug.cgi?id=660
This is perhaps a Subversion bug, but I think the Subversion team
should first concentrate on giving us the ability to configure it the
way we want without needing to resort to tricks like redirecting or
rewriting.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Mar 26 01:22:25 2006