You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Cliff Stanford <cl...@may.be> on 2007/02/23 21:20:45 UTC
SVNParentPath Revisited
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
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;
It was posted at
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=110383
I take Max's point that this can be fixed by editing the httpd.conf file
(or one included) but this takes away the ability to add a new
repository with just svnadmin create.
If you don't like the fix above, a number of other suggestions have been
made. Perhaps SVNReposName "%s" or an entirely new directive?
Please reconsider this problem. I'm happy to do the work for whatever
scheme you select.
Many thanks.
Cliff.
- --
Cliff Stanford
Might Limited +44 845 0045 666 (Office)
Suite 67, Dorset House +44 7973 616 666 (Mobile)
Duke Street, Chelmsford, CM1 1TB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF31qtfNTx9pWyKfwRAqNnAJ4yqXJznaAoDX/UMJz65s6jNI77VwCfb5OL
hywas6cU+vcwJ97HAuDg3wk=
=pMVM
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVNParentPath Revisited
Posted by "C. Michael Pilato" <cm...@collab.net>.
Max Bowsher wrote:
> A free-form human-targeted description, and the repository basename, are
> rather different things.
Granted.
> 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.
That seems fair. (Though, it's not used only for XSLT; the regular ol' HTML
display uses repo_name, too.)
>> 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?
Sorry. I was trying to draw an analogy here, but I realize now it's a
really bad one.
>> 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?
http://svn.haxx.se/dev/archive-2006-01/0392.shtml
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: SVNParentPath Revisited
Posted by Cliff Stanford <cl...@may.be>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Max Bowsher wrote:
> So, that means you're pretty much free to add attributes at will, free
> to add elements with a little care, and probably can't make any other
> kind of change, at least without some very careful thought.
I posted the patch to
http://subversion.tigris.org/issues/show_bug.cgi?id=2738 but I'm not
sure if there's something else I should have done.
Regards,
Cliff.
- --
Cliff Stanford
Might Limited +44 845 0045 666 (Office)
Suite 67, Dorset House +44 7973 616 666 (Mobile)
Duke Street, Chelmsford, CM1 1TB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGCbROfNTx9pWyKfwRAjIpAJ9Aj0zaXjG8+njWkraRzaTKUpGNGQCZAWoy
8O/RDi0LmGSM7pbK9xQawes=
=qQ9r
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVNParentPath Revisited
Posted by Max Bowsher <ma...@ukf.net>.
Cliff Stanford wrote:
> Max Bowsher wrote:
>
>>> 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.
>
> OK. Sounds good to me. I shall prepare a patch to that effect.
>
> Does anyone care if the DTD changes as it's internal to the document?
I'd say the important thing is that the XML remain compatible with
existing XSL transformations.
So, that means you're pretty much free to add attributes at will, free
to add elements with a little care, and probably can't make any other
kind of change, at least without some very careful thought.
Max.
Re: SVNParentPath Revisited
Posted by Cliff Stanford <cl...@may.be>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Max Bowsher wrote:
> 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.
OK. Sounds good to me. I shall prepare a patch to that effect.
Does anyone care if the DTD changes as it's internal to the document?
Regards,
Cliff.
- --
Cliff Stanford
Might Limited +44 845 0045 666 (Office)
Suite 67, Dorset House +44 7973 616 666 (Mobile)
Duke Street, Chelmsford, CM1 1TB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF5Ep6fNTx9pWyKfwRAmOuAKCRsbpnJwiIi6BeUNfQkmzqBHae6gCgtC1H
PJchKgN/NCLcD2ixhMauOmI=
=4drz
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVNParentPath Revisited
Posted by Max Bowsher <ma...@ukf.net>.
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.
Re: SVNParentPath Revisited
Posted by "C. Michael Pilato" <cm...@collab.net>.
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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand