[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVNParentPath Revisited

From: Max Bowsher <maxb1_at_ukf.net>
Date: 2007-02-25 19:29:45 CET

C. Michael Pilato wrote:
> 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".

Certainly.

A free-form human-targeted description, and the repository basename, are
rather different things.

I don't like the idea of blurring the distinction between the two,
because it opens the door for people to write code that assumes the
value can be used as an URL component, which would not always be true.

Also, anyone writing something to view the an enumeration of the
repositories under a SVNParentPath, then has to jump through unnecessary
hoops to work out whether there was a description configured for a
repository, or if it's just a repetition of its basename.

If it's desired that the repository basename be available to XSLT
presentation layers, then let us make it available using a new element
or attribute. I feel this would be far cleaner than overriding an
existing concept with an additional meaning.

> 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 am confused. SVNReposName is solely concerned with presentational
output. What does it have to do with URLs at all?

(Also, what do you mean: "the default URL for an ... URL"? That's a
parse failure in my brain :-) )

> 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.

Still confused by the previous bit, so unsure how to respond to that.

...

> 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.

I've been less than thorough at following the list of late. Could
someone give a pointer?

Thanks.
Max.

Received on Sun Feb 25 19:30:23 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.