Re: SVNParentPath Revisited

Cliff Stanford wrote:
> In the response to last time I brought this up,
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=110783
>
> Max Bowsher said:
>
>> After contemplation, I have come to realize that this entire thread is
>> founded on an inaccurate assumption - that it is impossible to set the
>> repository name in a SVNParentPath setup. This is not true:
>
>> <Location /repos>
>> DAV svn
>> SVNParentPath /foo
>> </Location>
>
>> <Location /repos/foo>
>> SVNReposName "This is the foo repository"
>> </Location>
>
>> <Location /repos/bar>
>> SVNReposName "This is the bar repository"
>> </Location>
>
>
>> The blurring of the concepts of repository filesystem basename and
>> SvnReposName human-style name as has been discussed in this thread,
>> would, in fact, be a bug itself - so let's not do that! :-)
>
> This is a plea for the dev team to reconsider. I have been able to
> build an entire svn repository browser, http://svn.may.be/ , built
> around only the repository and dav_svn. As I create a new svn repostory
> it appears automatically in the list and all the functions work on it.

Hrm. Yeah, I think Max might owe you (and the rest of us) something to back
the claim that "blurring of the concepts of repository filesystem basename
and SvnReposName human-style name as has been discussed in this thread,
would, in fact, be a bug itself". It is already the case that, where
SvnReposName is not provided, the default URL for an SVNParentPath-included
URL has as its basename the basename of the repository directory on-disk. I
can think of not a single reason not to assume that same default value as
the "name of the repository" unless otherwise overridden by the SVNReposName
directive.

> The problem is that, in order to work, I have to make the patch to the
> source on each release. It's only a two-liner but it shouldn't be
> necessary. The patch I use is to add the following lines after getting
> the repo_name in repos.c.
>
> if (repo_name == NULL)
> repo_name = repos_name;

I haven't reviewed the patch, but it sure seems to make sense to me
conceptually.

I notice, though, that there was another (much larger) patch around this
same topic. I think that patch takes the more thorough approach. I see
also that David Anderson was +1 on that patch, too, even claiming he'd usher
it into the codebase soonish.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand