Ben Collins-Sussman wrote:
> On May 8, 2005, at 7:28 AM, Michael Sinz wrote:
>>> Try setting the SVNReposName parameter in the <Location> in httpd.conf.
>>> How else do you expect mod_dav_svn could know what the repository
>>> name is?
>> That only works when you have only one repository. When you use SVNParentPath
>> the repository name is "implied" by the next element in the URL which is not exposed
>> in the XML or the HTML returned by mod_dav_svn.
> Michael -- I'm not sure I understand the problem you're trying to solve.
The situation is that I have a number of clients that have more than one
repository on their servers. When browsing a repository using the features
of the mod_dav_svn HTTP GET, there is no visual indication of which repository
you are in other than by the user looking at the URL in the URL bar (if visible)
The XML/XSLT or the HTML shows the path within the repository but not which one.
This means that printing a directory listing or otherwise just looking at the
page does not give that information.
I have a nasty workaround where some JavaScript in the page generated by the XSLT
parses the document.location for the repository name. It works but is a kludge
and requires some trickery to get the repository name correct depending on where
the location is set for the SVNParentPath. (Is it /svn/* or /repos/* or /work/cms/* ?)
> You know that mod_dav_svn provides a public API which examines any
> incoming URL and gives you back (1) the repository's name, (2) the path
> within the repository that the URL refers to... right?
Yes, that is understood for custom clients. I was building this with web browsers
and XMLHttp and JavaScript. No software to install for read-only access to the
repository.
> Modules like mod_authz_svn (and marcus's new mod_authn_svn module)
> depend on this API, since only mod_dav_svn knows how to interpret the
> funky-looking opaque urls it generates and forces the svn client to
> use. It alsos work on normal public urls as well. Maybe Insurrection
> could use it too? Look at dav_svn_split_uri() in mod_dav_svn.h.
The other problem I have is when working on the server side but that is just
my fault for not building this as a direct SVN module but as a layer on top of
the SVN commands. I am wondering if that was a mistake. I like the fact that
doing it this way does not depend on library linkages (old-school unix pipe/etc
connections) but it does seem to have a number of limitations. I was just
trying to find out which way the Subversion project would best like to move.
BTW - I really do like Subversion a lot and mainly use the command line tools
for all of my work. I have a number of clients that are now switched over to
or are switching to Subversion from other solutions. (Most of them are moving
from SourceSafe - what a horrible tool that is) And TortoiseSVN is a great
way to sell the non-engineers (and some engineers) on using revision control.
(Those requirements documents and project plans should be revision tracked too!)
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 8 19:22:27 2005