You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2003/05/27 19:36:31 UTC
RFC: a permanent svn-specific URL syntax
New users come up with this question over and over again:
"I need a public URL that represents a (rev, path) pair in the repository."
Our answer up till now has always been:
* mod_dav_svn has a secret format for this, but it is always subject
to change, so it basically dosen't exist.
* just use 'svn [cat|ls] -rN URL'
* or just use ViewCVS
But I've mentioned this before: I can't think of a reason *not* to
implement this feature. Our canned repsonses are mainly blow-offs,
and don't address the utility of the feature itself. I don't think
anyone would argue that it's not useful. It's just a matter of
getting consensus that
A) we all want a new, permanent, public, non-changing URL syntax
B) we're willing to support the permanent syntax.
Is this true? I don't think it would be very hard to support, and it
would benefit users greatly.
I'll just file a new feature request, assuming nobody has any
objections. Speak up if you object.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Ben Collins-Sussman <su...@collab.net>.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> --On Tuesday, May 27, 2003 2:36 PM -0500 Ben Collins-Sussman
> <su...@collab.net> wrote:
>
> > Is this true? I don't think it would be very hard to support, and it
> > would benefit users greatly.
>
> As long as the URL semantics and syntax are clean. That's going to be
> the fun part. It needs to be done in a way that doesn't prohibit
> users from having files named certain things. =)
>
> I'll be curious to see what you have in mind. -- justin
I'm not going to propose anything specific at the moment, I'm just
going to file a feature-issue. No time to actually debate or
implement this. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, May 27, 2003 2:36 PM -0500 Ben Collins-Sussman
<su...@collab.net> wrote:
> Is this true? I don't think it would be very hard to support, and it
> would benefit users greatly.
As long as the URL semantics and syntax are clean. That's going to be the fun
part. It needs to be done in a way that doesn't prohibit users from having
files named certain things. =)
I'll be curious to see what you have in mind. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Greg Stein <gs...@lyra.org>.
On Tue, May 27, 2003 at 10:17:08PM -0500, Ben Collins-Sussman wrote:
> Daniel Patterson <da...@adaptiveinternational.com> writes:
>...
> > A web interface is a pretty major selling point for SVN here, a reliable
> > way to allow browsing through history would be good :)
>
> The problem here is that we don't want to make Subversion into a
> complete ViewCVS replacement. ViewCVS already does a really beautiful
> job displaying older revisions, log history, and diffs. Pushing
> Subversion into that territory reinvents a wheel and becomes extra
> feature-bloat we have to support.
Yah. I was cranky enough when the XML/XSLT stuff was added. Subversion is in
the business of providing a versioning tool, and we can (and do) rely on
external tools to provide all the extra snazzy functionality.
> So it's a slippery slope: at the moment, many people are frustrated
> that Subversion only displays the HEAD revision to ordinary web
> browsers. Most of us think it's necessary to add the ability to
> browse an arbitrary revision. But I hope we draw the line there.
Bah. Where was the line with adding XML/XSLT output? Oh, and how about the
addition of the SVNReposName directive? Where were the lines there?
Don't kid yourself... it keeps moving every time somebody suggests "this one
simple little change". Three years from now, you could be looking at an
entirely different beast. Bit by bit...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Ben Collins-Sussman <su...@collab.net>.
Daniel Patterson <da...@adaptiveinternational.com> writes:
> Currently, we use "/repos/!svn/bc/234/<path>", which simply seemd to be
> one that works, it would be nice to have a documnented interface to use.
Careful, that URL format is an mod_dav_svn internal implementation
detail, subject to be changed at any time. In fact, it *has* been
changed in the past, as deltaV allows that. Not wise to rely on it.
> A web interface is a pretty major selling point for SVN here, a reliable
> way to allow browsing through history would be good :)
The problem here is that we don't want to make Subversion into a
complete ViewCVS replacement. ViewCVS already does a really beautiful
job displaying older revisions, log history, and diffs. Pushing
Subversion into that territory reinvents a wheel and becomes extra
feature-bloat we have to support.
So it's a slippery slope: at the moment, many people are frustrated
that Subversion only displays the HEAD revision to ordinary web
browsers. Most of us think it's necessary to add the ability to
browse an arbitrary revision. But I hope we draw the line there.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Daniel Patterson <da...@adaptiveinternational.com>.
On Wed, 2003-05-28 at 05:36, Ben Collins-Sussman wrote:
> New users come up with this question over and over again:
>
> "I need a public URL that represents a (rev, path) pair in the repository."
>
> Our answer up till now has always been:
>
> * mod_dav_svn has a secret format for this, but it is always subject
> to change, so it basically dosen't exist.
>
> * just use 'svn [cat|ls] -rN URL'
>
> * or just use ViewCVS
>
>
> But I've mentioned this before: I can't think of a reason *not* to
> implement this feature. Our canned repsonses are mainly blow-offs,
> and don't address the utility of the feature itself. I don't think
> anyone would argue that it's not useful. It's just a matter of
> getting consensus that
>
> A) we all want a new, permanent, public, non-changing URL syntax
>
> B) we're willing to support the permanent syntax.
>
> Is this true? I don't think it would be very hard to support, and it
> would benefit users greatly.
+1 to this. Using the XSLT function, and a small patch to mod_dav_svn,
we've already customised the "web browseable interface" to show:
Author
Last modified time
Size
Last modified revision
There are links everywhere, which allow users to easily browse through
time (skip back to the last modified revision quickly). We have "last
revision" and "next revision" links generated by the XSLT that allow
users to browse backwards and forwards revision by revision.
Currently, we use "/repos/!svn/bc/234/<path>", which simply seemd to be
one that works, it would be nice to have a documnented interface to use.
A web interface is a pretty major selling point for SVN here, a reliable
way to allow browsing through history would be good :)
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Mukund <mu...@tessna.com>.
On Wed, May 28, 2003 at 03:59:38PM +0100, Colin Watson wrote:
| Something like this also allows access control to be used easily on both
| HEAD URLs and revision URLs. Using path-info as in "/revision" looks
| ideal for files because it ensures that it can't possibly clash with a
| real entry in the repository, but is not so good for directories.
| Perhaps "?rev=revision" would be simplest.
I agree that a CGI based method of specifying the revision is a good
way to implement this. This way, even if the feature is to disappear in a
future release, the URLs are carry the same meaning as now (assuming that
the CGI variables aren't re-assigned).
---
On a side note, please consider the expansion of $URL$ to take this
into account -- it is easy for the current $URL$ keyword expansion in
files (distributed to customers) to be invalid on a future date
(when a file/directory is renamed or deleted), although the
repository is still the same.
$URL$ can typically be a part of unused static char
strings -- something like rcsid[] typically used in builds distributed to
customers -- which can be listed using 'ident' on binaries (for example).
Instead of $URL$ expanding to:
$URL: http://developer.internal.site/repository/some/path/Complex.h $
it may expand to something like the following:
$URL: http://developer.internal.site/repository/some/path/Complex.h?rev=6018 $
Mukund
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Bruce Atherton <br...@callenish.com>.
At 02:31 PM 6/4/2003 -0700, Greg Stein wrote:
> >From a pure HTTP/URL/resource modelling standpoint, it would make sense.
>When you toss WebDAV into the mix, it blows up :-(
>
>
>Can we end this discussion for now? None of this applies to 1.0 :-(
Yup. You've convinced me it is a harder problem than I had thought.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jun 04, 2003 at 12:13:06PM -0700, John Locke wrote:
>...
> I love a lively debate. I'll yield if you can show me how I might
> implement granular access control (both commit and update) using my
> choice of Apache authentication modules on the day this feature were to
> become available...
The access controls (should) also apply to paths that use ';' params.
Apache's parsing function lumps those right in with the rest of the
abs_path, as it should.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: RFC: a permanent svn-specific URL syntax
Posted by Sander Striker <st...@apache.org>.
> From: sussman@collab.net [mailto:sussman@collab.net]
> Sent: Thursday, June 05, 2003 4:28 AM
> "John Locke" <ma...@freelock.com> writes:
>
> > Ben Collins-Sussman said:
> >
> > > These other folks are talking about writing an authorization module --
> > > deciding who is allowed to read/write to specific areas of the
> > > repository.
> > >
> > > Can't apache already do LDAP authentication?
> > >
> > Sure it can... and authorization as you describe is exactly what I'm
> > after. I guess I wanted to make the suggestion that anybody coding an
> > authorization module allow for the use of any of the existing
> > authentication modules.
>
> If I understand apache correctly, it has a very clean separation
> between pluggable authn and authz modules. You can mix and match as
> you choose, for the most part.
>
> Apache folk: is my understanding correct?
For 2.1, yes. 2.0 still has got authn and authz intertwined mostly.
Shouldn't hold you back though.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Ben Collins-Sussman <su...@collab.net>.
"John Locke" <ma...@freelock.com> writes:
> Ben Collins-Sussman said:
>
> > These other folks are talking about writing an authorization module --
> > deciding who is allowed to read/write to specific areas of the
> > repository.
> >
> > Can't apache already do LDAP authentication?
> >
> Sure it can... and authorization as you describe is exactly what I'm
> after. I guess I wanted to make the suggestion that anybody coding an
> authorization module allow for the use of any of the existing
> authentication modules.
If I understand apache correctly, it has a very clean separation
between pluggable authn and authz modules. You can mix and match as
you choose, for the most part.
Apache folk: is my understanding correct?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by John Locke <ma...@freelock.com>.
Ben Collins-Sussman said:
> These other folks are talking about writing an authorization module --
> deciding who is allowed to read/write to specific areas of the
> repository.
>
> Can't apache already do LDAP authentication?
>
Sure it can... and authorization as you describe is exactly what I'm
after. I guess I wanted to make the suggestion that anybody coding an
authorization module allow for the use of any of the existing
authentication modules.
Okay. Guess I'm stating the obvious... I'll go back to lurking now.
Cheers,
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: RFC: a permanent svn-specific URL syntax
Posted by Sander Striker <st...@apache.org>.
> From: sussman@collab.net [mailto:sussman@collab.net]
> Sent: Thursday, June 05, 2003 1:14 AM
> John Locke <ma...@freelock.com> writes:
>
> > Any chance it can accommodate LDAP?
> >
>
> You're confusing authentication (authn) with authorization (authz).
>
> LDAP is about identifying a user -- authentication.
>
> These other folks are talking about writing an authorization module --
> deciding who is allowed to read/write to specific areas of the
> repository.
>
> Can't apache already do LDAP authentication?
Yes.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Ben Collins-Sussman <su...@collab.net>.
John Locke <ma...@freelock.com> writes:
> Any chance it can accommodate LDAP?
>
You're confusing authentication (authn) with authorization (authz).
LDAP is about identifying a user -- authentication.
These other folks are talking about writing an authorization module --
deciding who is allowed to read/write to specific areas of the
repository.
Can't apache already do LDAP authentication?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: RFC: a permanent svn-specific URL syntax
Posted by John Locke <ma...@freelock.com>.
On Wed, 2003-06-04 at 15:01, Sander Striker wrote:
> Then, authorization. This can be implemented fairly simply as discussed
> in:
> http://www.contactor.se/~dast/svn/archive-2003-06/0113.shtml
>
> Which has a link to a previous explanation aswell.
>
Okay, thanks for setting me straight on all this.
I eagerly await TTimo's attempt at a custom Apache auth module--this is
the type of thing I really need. The coding looks a bit beyond me,
though.
Any chance it can accommodate LDAP?
Cheers,
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: RFC: a permanent svn-specific URL syntax
Posted by Sander Striker <st...@apache.org>.
> From: John Locke [mailto:mail@freelock.com]
> Sent: Wednesday, June 04, 2003 9:13 PM
[...]
> My concern with
>
> http://my.svn.org/project/branch/file.c;rev=1010
>
> is that I can't control access to the previous version of resource
> file.c without specifying each and every rev in my <Location> block.
> Whereas by putting it in the query string, Apache ignores it.
Bzzt, won't work. Subversion will still use the special urls, so the
authz argument is out the window.
>> Of course. That is why using a semicolon makes sense. It is already part of
>> the RFC for URLs (as I quoted previously) and it does not abuse the query
>> string by using it in an incorrect way.
>
> Okay. I admit my ignorance of the standards. I'm a practical kind of
> guy--I just want it all to work. Standard or no, does the semi-colon
> syntax work with access controls that exist today? If so, I have no
> problem with it--just never seen it in use.
Access control is a moot argument.
> I still fail to see why this is an abuse of the query string, though. I
> understand your point about the revision being the primary resource (and
> I agree that that's how it should be, and one of the reasons
> Subversion's better than CVS), we're just arguing semantics of the URL,
> and my point is that there are lots of precedents for the syntax I
> propose, whether it's correct or not, while I haven't seen the syntax
> you propose.
Greg explained this in his reply.
[...]
> I'm just saying your way involves implementing something that doesn't
> integrate well with how people would want to USE this feature in real
> life, at least as far as access control is concerned--
And there it is again...
> and what I'm voting for is a shorthand with widespread use (correct or not) that
> should be fairly straightforward to implement (okay, implementation is
> probably a wash here), and uses the existing behavior/expectations
> already set by svn update.
The permanent svn-specific url syntax would be an _additional_ feature.
The other, 'special', urls won't go away. The svn client library won't
use the permanent public syntax, but the syntax it is using now. This
is why the authz argument is invalid.
Then, authorization. This can be implemented fairly simply as discussed
in:
http://www.contactor.se/~dast/svn/archive-2003-06/0113.shtml
Which has a link to a previous explanation aswell.
Sander
PS. Given the confusion introduced wrt authorization I wanted to get that
cleared up. Please don't continue the thread due to this post.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by John Locke <ma...@freelock.com>.
On Wed, 2003-06-04 at 10:48, Bruce Atherton wrote:
> A simple URL, yes. But why insist on a query string? There are other ways
> of accomplishing the same thing.
>
If they accomplish the same thing, fine. I'm just concerned that the
other ways will require custom ways of writing authentication schemes,
something that may delay the ability to implement them for quite a while
longer.
>
> >Again I see your point, but I'm coming at this from a user perspective,
> >not a developer perspective.
>
> As a user, how is this:
>
> http://my.svn.org/project/branch/file.c?rev=1010
>
> different from this:
>
> http://my.svn.org/project/branch/file.c;rev=1010
>
> The first says that the resource is "file.c", and that a query is applied
> against that resource. The second says that the resource is "file.c with a
> parameter of rev=1010".
>
But this isn't necessarily the case.
http://my.svn.org/project/branch/file.c?rev=1010
might refer to a resource named file.c--but it's possible that the
resource is actually /project/branch, or even just /project. In my Team
Checkin site, for example, if you go to
http://teamcheckin.com/game/fiddlers/?gameID=59, what is the resource?
Trick question--the script that is running is /game. The /fiddlers is
parsed into a query for the database, the ?gameID=59 is used as the time
value, which I can provide using either GET or POST. In Perl and PHP,
you can get at the /fiddlers/ part by using the $PATH_INFO server
variable that Apache passes to the script when it finds that /game is a
script, not a directory. Now I don't know if this is technically
correct--all I know is our soccer team kicked butt Monday night.
But by making /fiddlers appear like a resource, it greatly simplifies
access control.
My concern with
http://my.svn.org/project/branch/file.c;rev=1010
is that I can't control access to the previous version of resource
file.c without specifying each and every rev in my <Location> block.
Whereas by putting it in the query string, Apache ignores it.
>
> Of course. That is why using a semicolon makes sense. It is already part of
> the RFC for URLs (as I quoted previously) and it does not abuse the query
> string by using it in an incorrect way.
>
Okay. I admit my ignorance of the standards. I'm a practical kind of
guy--I just want it all to work. Standard or no, does the semi-colon
syntax work with access controls that exist today? If so, I have no
problem with it--just never seen it in use.
I still fail to see why this is an abuse of the query string, though. I
understand your point about the revision being the primary resource (and
I agree that that's how it should be, and one of the reasons
Subversion's better than CVS), we're just arguing semantics of the URL,
and my point is that there are lots of precedents for the syntax I
propose, whether it's correct or not, while I haven't seen the syntax
you propose.
Now everyone knows the world revolves around me so we should do it my
way ;-)
No, seriously, I understand that Subversion strives to comply to the
RFCs, and that from a data modeling standpoint, your suggestion may be
more accurate.
I'm just saying your way involves implementing something that doesn't
integrate well with how people would want to USE this feature in real
life, at least as far as access control is concerned--and what I'm
voting for is a shorthand with widespread use (correct or not) that
should be fairly straightforward to implement (okay, implementation is
probably a wash here), and uses the existing behavior/expectations
already set by svn update.
I love a lively debate. I'll yield if you can show me how I might
implement granular access control (both commit and update) using my
choice of Apache authentication modules on the day this feature were to
become available...
Cheers,
--
John Locke
http://freelock.com
Recently published: "Extend the reach of users' email with IMAP"
http://www.techrepublic.com/article_guest.jhtml?id=r00620030507jxl01.htm
Play sports? Check in at http://teamcheckin.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Greg Stein <gs...@lyra.org>.
Bruce is quite right here. Short summary is: query string is out, and using
the path is in. "Period" :-)
On Wed, Jun 04, 2003 at 10:48:41AM -0700, Bruce Atherton wrote:
> At 11:08 PM 6/3/2003 -0700, John Locke wrote:
> >Well, there's the example of the svn update command to emulate--I don't
> >see that it needs to behave any differently.
>
> The purpose of the svn-specific URL syntax is to provide a way to uniquely
> identify a resource. You seem to think that only the file represents a
> resource, but DeltaV's specification (which Subversion is trying to get
> closer to) makes the revision a resource as well, called a "Version
> Resource".
Exactly. The standards out there specify that a particular revision of a
particular file is a *distinct resource*. That implies it must use a
distinct URL to locate it. Simple as that.
The query component of a URL does not differentiate between resources, so
they cannot be used in this situation.
> None of this has anything to do with the "svn" application or its update
> command, save that the client will probably need to support the URL syntax
> at some point.
Correct. DeltaV specifies the modelling of the resources, and that directly
implies how we can use a URL.
Although, I'm not sure that we can construct a URL syntax that can be built
by the client. More below.
>...
> >Again I see your point, but I'm coming at this from a user perspective,
> >not a developer perspective.
>
> As a user, how is this:
>
> http://my.svn.org/project/branch/file.c?rev=1010
>
> different from this:
>
> http://my.svn.org/project/branch/file.c;rev=1010
>
> The first says that the resource is "file.c", and that a query is applied
> against that resource. The second says that the resource is "file.c with a
> parameter of rev=1010".
Re: RFC: a permanent svn-specific URL syntax
Posted by Bruce Atherton <br...@callenish.com>.
At 11:08 PM 6/3/2003 -0700, John Locke wrote:
>Well, there's the example of the svn update command to emulate--I don't
>see that it needs to behave any differently.
The purpose of the svn-specific URL syntax is to provide a way to uniquely
identify a resource. You seem to think that only the file represents a
resource, but DeltaV's specification (which Subversion is trying to get
closer to) makes the revision a resource as well, called a "Version Resource".
None of this has anything to do with the "svn" application or its update
command, save that the client will probably need to support the URL syntax
at some point.
>I see your point, but this is an implementation detail. Seems to me that
>if you actually want to see an earlier version of a file, then you ought
>to be able to put together a simple URL with a query string to do it.
A simple URL, yes. But why insist on a query string? There are other ways
of accomplishing the same thing.
>Again I see your point, but I'm coming at this from a user perspective,
>not a developer perspective.
As a user, how is this:
http://my.svn.org/project/branch/file.c?rev=1010
different from this:
http://my.svn.org/project/branch/file.c;rev=1010
The first says that the resource is "file.c", and that a query is applied
against that resource. The second says that the resource is "file.c with a
parameter of rev=1010".
>I just hope that any URL scheme the project chooses to implement for
>accessing different versions in the repository follows existing
>conventions, rather than creating new ones. And being a web developer, I
>prefer web conventions...
Of course. That is why using a semicolon makes sense. It is already part of
the RFC for URLs (as I quoted previously) and it does not abuse the query
string by using it in an incorrect way.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by John Locke <ma...@freelock.com>.
William,
Thanks for putting the difference in clear language. I appreciate
everyone taking the time to educate me on this...
On Wed, 2003-06-04 at 03:53, William Uther wrote:
> There are two different things you can ask for:
>
> i) What the file in HEAD called 'blah' looked like in revision X.
> ii) What the file in revision X called 'blah' looks like.
>
> These are very different things. If svn were to include viewcvs, then
> it would need to display both. It is not clear to me which of these
> you think svn should display.
>
> > When you view a directory, it also seems to me that it shouldn't be
> > difficult to append the query string to each of the links in the
> > directory, so you can browse the revision to see all the files.
>
> So you want a query of type i)?
>
Actually, I haven't extensively played around with svn mv, but I would
expect the behavior of type ii).
As the book says about svn switch, we have two dimensions to work with:
time and space. So what I would expect is that the query string
specifies the time, and the path specifies the space.
If a file exists at whatever time (revision) specified in the query
string, then I would expect to get the file at that revision with the
specified name--not the version of the file with that name in the HEAD
branch at the specified revision.
I guess where I seem to be differing from everyone else is that I see
the query string as completely independent of the path.
What I would expect out of this is exactly the behavior of svn
update--if there's a revision specified, get the file at the revision
with the name you specified. If there's no revision specified, get the
HEAD revision. If the file doesn't exist in a particular revision,
return 404. If a directory was specified, show the contents a la svn ls.
In fact, the more I think about it, the more I don't see the need for
type I) in a web interface at all--that's what the log is for, to tell
you how the file has changed over time. What I want to be able to do is
just get whatever is there at the specified time (revision).
I can't imagine this would be hard to implement--hooking the update code
to the web client. I've built web sites that pass a couple dimensions of
an array in the path, and still pass a query string that can completely
change what is returned in the page.
Again, I'm coming at this from a user point of view--I have a need to
retrieve earlier versions of a file from my repository from machines
without Subversion installed (at a client site, for example). I also
have a need to segment my repository so that I can provide such a URL to
a client and not give them access to other client's files, which is what
I currently can't do without creating entirely separate repositories.
Which is why a URL schema would be great.
The biggest reason I want the TIME component to come after the SPACE
component in the URL, is because that's how I want to segment
access/authorization to the repository. I can't think of a reason I
would need to block access to individual revisions of a file--I could
just add a copy somewhere else if I really had that need. But there's
plenty of reasons I want to protect branches, tags, and whole sections
of the repository, and I see a consistent URL scheme as being the
easiest way to do this.
Cheers,
--
John Locke
http://freelock.com
Recently published: "Extend the reach of users' email with IMAP"
http://www.techrepublic.com/article_guest.jhtml?id=r00620030507jxl01.htm
Play sports? Check in at http://teamcheckin.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by William Uther <wi...@cse.unsw.edu.au>.
On Wednesday, June 4, 2003, at 04:08 PM, John Locke wrote:
>> What you're actually asking the repository for is a revision of the
>> tree, and then a particular resource within that tree (i.e. the
>> tree is the *first* thing to be found, from the revision number).
>> Going to the resource first, then moving backwards, is, well,
>> backwards.
>>
> I see your point, but this is an implementation detail.
No, it isn't an implementation detail, it is a storage model detail.
It doesn't matter if it is implemented in paper cards on a pile on the
floor, the revision choice is made first (see below for an example).
> Seems to me that
> if you actually want to see an earlier version of a file, then you
> ought
> to be able to put together a simple URL with a query string to do it.
There are two different things you can ask for:
i) What the file in HEAD called 'blah' looked like in revision X.
ii) What the file in revision X called 'blah' looks like.
These are very different things. If svn were to include viewcvs, then
it would need to display both. It is not clear to me which of these
you think svn should display.
> When you view a directory, it also seems to me that it shouldn't be
> difficult to append the query string to each of the links in the
> directory, so you can browse the revision to see all the files.
So you want a query of type i)?
> I still don't see why this is a bad thing.
It isn't a bad thing per se, but it isn't what people have been
discussing. They've been discussing queries of type ii). Your
suggestion is quite good for queries of type i).
I should also say that I'm not sure subversion should have this
functionality (either type) at all. Once we support one of these types
of queries, there will be a call to support the other, then to...
For an example of where these two types of query differ:
mkdir testsvn
cd testsvn
svnadmin create repos
svn co file://`pwd`/repos trunk
cd trunk
echo "FileA" > file1
echo "FileB" > file2
svn add file1 file2
svn commit -m "added file1 and file2"
svn rm file1
svn commit -m "removed file1"
svn mv file2 file1
svn commit -m "moved file2 to file1"
Now, when look at the contents of file1 at revision 1, what do you
expect to see? "FileA", or "FileB"?
Your syntax would suggest to me you expected to see "FileB" - If you
take file1 and follow its history back to revision 1, it contains the
text "FileB". (This is easy to see: it contains the same text in all
revisions as the text never changes.)
Other people are talking about finding a way to view the text "FileA".
Note that there is NO file in head that corresponds to the file we want
to look at - it has been removed. We need a type ii) query as no type
i) query will give us what we want. This is why people have been
talking about type ii) queries - they allow access to everything,
whereas type i) queries do not.
With a type ii) query, the revision changes the meaning of the path.
For this reason people are arguing that it should come first in the
URL. (As I said above, I wouldn't put either in, but I don't really
care - I'm not going to be maintaining it.)
Cheers,
Will :-}
--
Dr William Uther National ICT Australia
Phone: +61 2 9385 6926 School of Computer Science and
Engineering
Email: willu@cse.unsw.edu.au University of New South Wales
Jabber: willu@jabber.cse.unsw.edu.au Sydney, Australia
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by John Locke <ma...@freelock.com>.
On Tue, 2003-06-03 at 16:41, Daniel Patterson wrote:
> But remember, a resource may not exist at certain revisions. Does
> it make sense to return a 404 because a query modifies what revision
> of a resource you're asking for, but a plain request for the resource
> itself returns a 200?
>
Well, there's the example of the svn update command to emulate--I don't
see that it needs to behave any differently.
> What you're actually asking the repository for is a revision of the
> tree, and then a particular resource within that tree (i.e. the
> tree is the *first* thing to be found, from the revision number).
> Going to the resource first, then moving backwards, is, well, backwards.
>
I see your point, but this is an implementation detail. Seems to me that
if you actually want to see an earlier version of a file, then you ought
to be able to put together a simple URL with a query string to do it.
When you view a directory, it also seems to me that it shouldn't be
difficult to append the query string to each of the links in the
directory, so you can browse the revision to see all the files.
I still don't see why this is a bad thing.
> I'd argue that a resource at a different revision is actually a
> different resource (i.e. the object resides in a different tree
> revision in the SVN filesystem). Each revision that bumps the
> repository version creates as many new resources as there are objects
> in your tree. The fact that SVN only stores changes is irrelevant.
> The model is that there is an entire new tree to browse (that looks
> mostly like the last one) that needs to be specified as part of the
> resource you're looking for.
Again I see your point, but I'm coming at this from a user perspective,
not a developer perspective.
What I'm looking to use Subversion for is to store different versions of
files--contracts, documents, marketing material, etc. Not source code.
The simple fact that Subversion does binary deltas already makes it one
of the best version control systems for this use. Providing easy
integration with a web server is the other compelling feature that has
made me a Subversion fan. And being able to request a revision based on
a date--Super!
I just hope that any URL scheme the project chooses to implement for
accessing different versions in the repository follows existing
conventions, rather than creating new ones. And being a web developer, I
prefer web conventions...
Cheers,
--
John Locke
http://freelock.com
Recently published: "Extend the reach of users' email with IMAP"
http://www.techrepublic.com/article_guest.jhtml?id=r00620030507jxl01.htm
Play sports? Check in at http://teamcheckin.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Daniel Patterson <da...@adaptiveinternational.com>.
On Wed, 2003-06-04 at 05:10, John Locke wrote:
> As a web developer, I disagree. As Greg states, the query string implies
> that there is *one* resource receiving different query values. In a web
> development setting, the "resource" might be a script that then goes to
> retrieve different content based on the query string.
But remember, a resource may not exist at certain revisions. Does
it make sense to return a 404 because a query modifies what revision
of a resource you're asking for, but a plain request for the resource
itself returns a 200?
What you're actually asking the repository for is a revision of the
tree, and then a particular resource within that tree (i.e. the
tree is the *first* thing to be found, from the revision number).
Going to the resource first, then moving backwards, is, well, backwards.
I'd argue that a resource at a different revision is actually a
different resource (i.e. the object resides in a different tree
revision in the SVN filesystem). Each revision that bumps the
repository version creates as many new resources as there are objects
in your tree. The fact that SVN only stores changes is irrelevant.
The model is that there is an entire new tree to browse (that looks
mostly like the last one) that needs to be specified as part of the
resource you're looking for.
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by John Locke <ma...@freelock.com>.
On Mon, 2003-06-02 at 09:37, Bruce Atherton wrote:
> At 09:58 PM 6/1/2003 -0700, Greg Stein wrote:
>
> > The ?rev=whatever form is not appropriate. The query string is
> > applied to
> > the resource specified by the other parts of the URL(*). i.e. it
> > implies
> > there is *one* resource receiving different query values. But that
> > isn't how
> > this stuff should be modelled -- we've got multiple resources. There
> > is one
> > for each revision. Thus, the revision number should be part of the
> > path
> > portion of the URL to get the proper modelling.
>
> I agree. I think the semicolon should be used, as that is specified by
> RFC 2396 as the way to specify parameters within the path component:
>
As a web developer, I disagree. As Greg states, the query string implies
that there is *one* resource receiving different query values. In a web
development setting, the "resource" might be a script that then goes to
retrieve different content based on the query string.
In fact, I'd argue that Subversion makes even more sense for using a
query string than most web sites--you have one resource (the file) with
a query string pointing to its contents at different revision levels.
Makes perfect sense, especially in a web server context.
--
John Locke
http://freelock.com
Recently published: "Extend the reach of users' email with IMAP"
http://www.techrepublic.com/article_guest.jhtml?id=r00620030507jxl01.htm
Play sports? Check in at http://teamcheckin.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Bruce Atherton <br...@callenish.com>.
At 09:58 PM 6/1/2003 -0700, Greg Stein wrote:
>The ?rev=whatever form is not appropriate. The query string is applied to
>the resource specified by the other parts of the URL(*). i.e. it implies
>there is *one* resource receiving different query values. But that isn't how
>this stuff should be modelled -- we've got multiple resources. There is one
>for each revision. Thus, the revision number should be part of the path
>portion of the URL to get the proper modelling.
I agree. I think the semicolon should be used, as that is specified by RFC
2396 as the way to specify parameters within the path component:
> Each path segment may include a sequence of parameters,
> indicated by the semicolon ";" character.
So the URL would look something like:
http://svn.something.net/repository/project/branch1/file.c;rev=1613
Re: RFC: a permanent svn-specific URL syntax
Posted by Greg Stein <gs...@lyra.org>.
On Wed, May 28, 2003 at 08:50:42AM -0700, Justin Erenkrantz wrote:
> --On Wednesday, May 28, 2003 5:31 PM +0200 Rafael Garcia-Suarez
> <ra...@hexaflux.com> wrote:
>
> >The simplest safe short solution is probably to use a # sign (ie. the
> >uri fragment syntax) :
> > http://svn.something.net/repository/project/branch1/file.c#1613
> >It has the same advantages than the path-info solution, but works for
>
> Eww. No. # are fragments and not really part of the resource, but part of
> the representation. # are usually interpreted by the client not the server.
>
> The next rev of the URI spec will explicitly call fragments out, but it's a
> landmine we don't want to go near. -- justin
And just to continue shooting this stuff down...
The ?rev=whatever form is not appropriate. The query string is applied to
the resource specified by the other parts of the URL(*). i.e. it implies
there is *one* resource receiving different query values. But that isn't how
this stuff should be modelled -- we've got multiple resources. There is one
for each revision. Thus, the revision number should be part of the path
portion of the URL to get the proper modelling.
Cheers,
-g
(*) see section 3.4 of RFC 2396
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, May 28, 2003 5:31 PM +0200 Rafael Garcia-Suarez
<ra...@hexaflux.com> wrote:
> The simplest safe short solution is probably to use a # sign (ie. the
> uri fragment syntax) :
> http://svn.something.net/repository/project/branch1/file.c#1613
> It has the same advantages than the path-info solution, but works for
Eww. No. # are fragments and not really part of the resource, but part of
the representation. # are usually interpreted by the client not the server.
The next rev of the URI spec will explicitly call fragments out, but it's a
landmine we don't want to go near. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
Colin Watson wrote:
> > http://svn.something.net/repository/project/branch1/file.c@1613
> > http://svn.something.net/repository/project/branch1/file.c/1613
> > http://svn.something.net/repository/project/branch1/file.c,1613
>
> Something like this also allows access control to be used easily on both
> HEAD URLs and revision URLs. Using path-info as in "/revision" looks
> ideal for files because it ensures that it can't possibly clash with a
> real entry in the repository, but is not so good for directories.
> Perhaps "?rev=revision" would be simplest.
The simplest safe short solution is probably to use a # sign (ie. the
uri fragment syntax) :
http://svn.something.net/repository/project/branch1/file.c#1613
It has the same advantages than the path-info solution, but works for
directories as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Colin Watson <cj...@flatline.org.uk>.
On Wed, May 28, 2003 at 12:47:05PM +0100, Mukund wrote:
> On Tue, May 27, 2003 at 02:36:31PM -0500, Ben Collins-Sussman wrote:
> | A) we all want a new, permanent, public, non-changing URL syntax
> |
> | B) we're willing to support the permanent syntax.
>
> Please let us keep the URL syntax to something which does not change how
> we know human visible URLs currently.
>
> i.e., if the visible URL currently is:
> http://svn.something.net/repository/project/branch1/file.c
>
> Then please let us keep the (rev, path) pair syntax of the URL similar
> to the above by appending the revision number in some conspicuous way.
>
> http://svn.something.net/repository/project/branch1/file.c@1613
> http://svn.something.net/repository/project/branch1/file.c/1613
> http://svn.something.net/repository/project/branch1/file.c,1613
Something like this also allows access control to be used easily on both
HEAD URLs and revision URLs. Using path-info as in "/revision" looks
ideal for files because it ensures that it can't possibly clash with a
real entry in the repository, but is not so good for directories.
Perhaps "?rev=revision" would be simplest.
--
Colin Watson [cjwatson@flatline.org.uk]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Colin Watson <cj...@flatline.org.uk>.
On Wed, May 28, 2003 at 11:32:55AM -0500, cmpilato@collab.net wrote:
> Colin Watson <cj...@flatline.org.uk> writes:
> > On Wed, May 28, 2003 at 06:01:17PM +0200, Sander Striker wrote:
> > > Indeed I did. Having this extra url feature, just means another thing
> > > to access control.
> >
> > Not really. It's rather rare to have access control that would treat
> > /foo/bar differently to /foo/bar?some-query-string.
>
> But not so rare to have access control that would treat
> /!svn/bc/1400/foo/bar differently than /foo/bar?some-query-string.
Quite. But normal use is to want to control access to /foo/bar and
/foo/bar?some-query-string in the same way; I think that wanting to
control access differently to HEAD and to previous revisions is rather
rarer.
--
Colin Watson [cjwatson@flatline.org.uk]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by cm...@collab.net.
Colin Watson <cj...@flatline.org.uk> writes:
> On Wed, May 28, 2003 at 06:01:17PM +0200, Sander Striker wrote:
> > From: sussman@collab.net [mailto:sussman@collab.net]
> > > I believe Sander already made earlier comments about how the '!svn'
> > > urls can be access-controlled.
> >
> > Indeed I did. Having this extra url feature, just means another thing
> > to access control.
>
> Not really. It's rather rare to have access control that would treat
> /foo/bar differently to /foo/bar?some-query-string.
But not so rare to have access control that would treat
/!svn/bc/1400/foo/bar differently than /foo/bar?some-query-string.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Colin Watson <cj...@flatline.org.uk>.
On Wed, May 28, 2003 at 06:01:17PM +0200, Sander Striker wrote:
> From: sussman@collab.net [mailto:sussman@collab.net]
> > I believe Sander already made earlier comments about how the '!svn'
> > urls can be access-controlled.
>
> Indeed I did. Having this extra url feature, just means another thing
> to access control.
Not really. It's rather rare to have access control that would treat
/foo/bar differently to /foo/bar?some-query-string.
--
Colin Watson [cjwatson@flatline.org.uk]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svn status and NT Junction points
Posted by Branko Čibej <br...@xbc.nu>.
I had similar problems, yes. I think a recent change in APR should fix
this. Up to then, APR was always reporting reparse points as symbolic
links, but should now do that only if specifically asked to do so.
Haven't tested it yet, though.
Mark Watts wrote:
>Has anyone else tried to work with Subversion Working Copies using NTFS
>(Win2K&WinXP) Junction Points. I am having problems getting it to work.
>Here is the setup
>
>d:\wccopies\trunk\src
>d:\wccopies\branch1\src
>d:\wccopies\branch2\src
>
>Where each 'src' directory is a full working copy checked out from
>Subversion. Now due to build requirements that I can not control the 'src'
>directory must be at the root of the drive, in my case d:
>
>Now I realize that I can use svn switch to switch my working copy around but
>I find it more convenient (esp. with 80 Gig drives today) to just have
>multiple working copies available and use the one I need for the current
>task. I set up a python script that will map '\wccopies\trunk\src' to
>'\src' so the build process will work. If I need to move to a different
>task on one of my branches the script can simply change the directory
>junction to point to the correct working copy and everything is setup.
>However it subversion does not seem to like directory junctions.
>
>When I go in an change a file in the '\src' directory tree and then run 'svn
>status' in '\svn' I get wrong information. At least I think it is wrong.
>Here is the table of the results that I get:
>
>Dir\Command Result
>\src\svn status "~ S ." // obstruction and switch
>\src\svn diff yields the correct
> diff of changed files
>\wccopies\trunk\src\svn status yields the correct
> status report of changed files
>\wccopies\trunk\\src\svn diff yields the correct
> diff of changed files
>
>Any ideas about what might be going wrong?
>
>PS: Junction is a free tool that you can obtain from
>http://www.sysinternals.com/ntw2k/source/misc.shtml#junction or if you have
>the Win2K Resource Kit you can also use the linkd program to create the
>directory junction.
>
>Thanks
>
>-Mark
>
>
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Svn status and NT Junction points
Posted by Mark Watts <mw...@stny.rr.com>.
Has anyone else tried to work with Subversion Working Copies using NTFS
(Win2K&WinXP) Junction Points. I am having problems getting it to work.
Here is the setup
d:\wccopies\trunk\src
d:\wccopies\branch1\src
d:\wccopies\branch2\src
Where each 'src' directory is a full working copy checked out from
Subversion. Now due to build requirements that I can not control the 'src'
directory must be at the root of the drive, in my case d:
Now I realize that I can use svn switch to switch my working copy around but
I find it more convenient (esp. with 80 Gig drives today) to just have
multiple working copies available and use the one I need for the current
task. I set up a python script that will map '\wccopies\trunk\src' to
'\src' so the build process will work. If I need to move to a different
task on one of my branches the script can simply change the directory
junction to point to the correct working copy and everything is setup.
However it subversion does not seem to like directory junctions.
When I go in an change a file in the '\src' directory tree and then run 'svn
status' in '\svn' I get wrong information. At least I think it is wrong.
Here is the table of the results that I get:
Dir\Command Result
\src\svn status "~ S ." // obstruction and switch
\src\svn diff yields the correct
diff of changed files
\wccopies\trunk\src\svn status yields the correct
status report of changed files
\wccopies\trunk\\src\svn diff yields the correct
diff of changed files
Any ideas about what might be going wrong?
PS: Junction is a free tool that you can obtain from
http://www.sysinternals.com/ntw2k/source/misc.shtml#junction or if you have
the Win2K Resource Kit you can also use the linkd program to create the
directory junction.
Thanks
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: RFC: a permanent svn-specific URL syntax
Posted by Sander Striker <st...@apache.org>.
> From: sussman@collab.net [mailto:sussman@collab.net]
> Sent: Wednesday, May 28, 2003 5:34 PM
>> On Wed, May 28, 2003 at 10:22:44AM -0500, Ben Collins-Sussman wrote:
>>> John Locke <ma...@freelock.com> writes:
>>>> http://svn.something.net/repository/project/branch1/file.c?r=1613
>>>
>>> I like this syntax, it's simple and safe, due to the laws of CGI, I
>>> guess. :-)
>>
>> Would these then become the *only* revision URLs (i.e. would
>> /svn/!bc/... or whatever it is disappear)? Doing that would definitely
>> ease access control.
>
> No, there's no reason for mod_dav_svn to stop producing "baseline
> collection" (bc) resource urls. It's part of the deltaV spec, and a
> deltaV client would expect it. Certainly ra_dav needs them, because
> it's trying to follow deltaV procedures as best it can.
>
> The point is that there would now be a human-friendly format, in
> addition to the deltaV-friendly format.
Exactly. It will be an _additional_ feature. Just like an option this
is yet another thing to take into account for maintenance. Surely if/when
we provide this, there will be request for other viewcvs features. I'd
rather punt on this feature and point people to viewcvs directly. The
proposed syntaxes already resemble the viewcvs ones anyway.
> I believe Sander already made earlier comments about how the '!svn'
> urls can be access-controlled.
Indeed I did. Having this extra url feature, just means another thing
to access control.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Ben Collins-Sussman <su...@collab.net>.
Colin Watson <cj...@flatline.org.uk> writes:
> On Wed, May 28, 2003 at 10:22:44AM -0500, Ben Collins-Sussman wrote:
> > John Locke <ma...@freelock.com> writes:
> > > http://svn.something.net/repository/project/branch1/file.c?r=1613
> >
> > I like this syntax, it's simple and safe, due to the laws of CGI, I
> > guess. :-)
>
> Would these then become the *only* revision URLs (i.e. would
> /svn/!bc/... or whatever it is disappear)? Doing that would definitely
> ease access control.
No, there's no reason for mod_dav_svn to stop producing "baseline
collection" (bc) resource urls. It's part of the deltaV spec, and a
deltaV client would expect it. Certainly ra_dav needs them, because
it's trying to follow deltaV procedures as best it can.
The point is that there would now be a human-friendly format, in
addition to the deltaV-friendly format.
I believe Sander already made earlier comments about how the '!svn'
urls can be access-controlled.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Colin Watson <cj...@flatline.org.uk>.
On Wed, May 28, 2003 at 10:22:44AM -0500, Ben Collins-Sussman wrote:
> John Locke <ma...@freelock.com> writes:
> > http://svn.something.net/repository/project/branch1/file.c?r=1613
>
> I like this syntax, it's simple and safe, due to the laws of CGI, I
> guess. :-)
Would these then become the *only* revision URLs (i.e. would
/svn/!bc/... or whatever it is disappear)? Doing that would definitely
ease access control.
Thanks,
--
Colin Watson [cjwatson@flatline.org.uk]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Ben Collins-Sussman <su...@collab.net>.
John Locke <ma...@freelock.com> writes:
> http://svn.something.net/repository/project/branch1/file.c?r=1613
I like this syntax, it's simple and safe, due to the laws of CGI, I
guess. :-)
> http://svn.something.net/repository/project/branch1/file.c?svn=diff&r=1489:1613
> (shows a diff of versions 1489 and 1613)
[cringe]
ViewCVS already shows diffs.
> http://svn.something.net/repository/project/branch1/file.c?svn=proplist&r=1489
[cringe again]
ViewCVS will show proplists someday.
> ... and you could even use this scheme for the svn client, using a PUT
> or POST to a URL:
>
> http://svn.something.net/repository/project/branch1/file.c?svn=ci&m=comment%20escaped%20for%20query%20string
Use a WebDAV client, not a web-browser, for PUTs.
> Does this sound like a reasonable solution?
Again, I would -1 such changes. I don't want to see Subversion morph
into a complete web-enabled version-browsing system. ViewCVS already
does this, and I don't want to reinvent (or support) a redundant
wheel.
I draw the line at http://host/repos/path?r=N .
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by John Locke <ma...@freelock.com>.
On Wed, 2003-05-28 at 04:47, Mukund wrote:
> Please let us keep the URL syntax to something which does not change how
> we know human visible URLs currently.
>
> i.e., if the visible URL currently is:
> http://svn.something.net/repository/project/branch1/file.c
>
> Then please let us keep the (rev, path) pair syntax of the URL similar
> to the above by appending the revision number in some conspicuous way.
>
> http://svn.something.net/repository/project/branch1/file.c@1613
> http://svn.something.net/repository/project/branch1/file.c/1613
> http://svn.something.net/repository/project/branch1/file.c,1613
>
> The above may be bad ideas for syntax -- they are just examples to
> illustrate how the current human visible URL can be kept intact.
>
As a web person, I'm particularly partial to a standard query string for
this--'?variable1=value&variable2=value'
I'd suggest we keep this simple, and use something corresponding to the
svn commands. So for a version, we could either use a human-readable
'version' for the variable, or perhaps better, the equivalent of -r:
http://svn.something.net/repository/project/branch1/file.c?version=1613
http://svn.something.net/repository/project/branch1/file.c?r=1613
http://svn.something.net/repository/project/branch1/file.c?r={2003-04-21}
http://svn.something.net/repository/project/branch1/file.c?r=PREV
This type of organization has the benefit of working well with Apache
authentication--the URL is hierarchical by location, rather than
revision, so you can grant/deny access to particular files/directories
for all revisions.
It seems that you could use this basic scheme to make a web client:
http://svn.something.net/repository/project/branch1/file.c?svn=diff&r=1489:1613
(shows a diff of versions 1489 and 1613)
http://svn.something.net/repository/project/branch1/file.c?svn=proplist&r=1489
(shows the property list for the file as of version 1489)
... and you could even use this scheme for the svn client, using a PUT
or POST to a URL:
http://svn.something.net/repository/project/branch1/file.c?svn=ci&m=comment%20escaped%20for%20query%20string
These variables can be part of the POST, instead of on the query
string...
If the URL schema changed to this sort of organization, it would make
authentication by Apache possible, and relatively straightforward. It
would also make it easy to make a full-fledged subversion web server
client, using PHP or equivalent.
Does this sound like a reasonable solution?
Cheers,
--
John Locke
http://freelock.com
Recently published: "Extend the reach of users' email with IMAP"
http://www.techrepublic.com/article_guest.jhtml?id=r00620030507jxl01.htm
Play sports? Check in at http://teamcheckin.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Mukund <mu...@tessna.com>.
On Tue, May 27, 2003 at 02:36:31PM -0500, Ben Collins-Sussman wrote:
| A) we all want a new, permanent, public, non-changing URL syntax
|
| B) we're willing to support the permanent syntax.
Please let us keep the URL syntax to something which does not change how
we know human visible URLs currently.
i.e., if the visible URL currently is:
http://svn.something.net/repository/project/branch1/file.c
Then please let us keep the (rev, path) pair syntax of the URL similar
to the above by appending the revision number in some conspicuous way.
http://svn.something.net/repository/project/branch1/file.c@1613
http://svn.something.net/repository/project/branch1/file.c/1613
http://svn.something.net/repository/project/branch1/file.c,1613
The above may be bad ideas for syntax -- they are just examples to
illustrate how the current human visible URL can be kept intact.
We could have a different way, like:
http://svn.something.net/repos/!svn/bc/234/<path>
but the above is more intuitive.
Mukund
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by John Locke <ma...@freelock.com>.
On Tue, 2003-05-27 at 12:36, Ben Collins-Sussman wrote:
> It's just a matter of
> getting consensus that
>
> A) we all want a new, permanent, public, non-changing URL syntax
>
> B) we're willing to support the permanent syntax.
>
> Is this true? I don't think it would be very hard to support, and it
> would benefit users greatly.
>
+1 here. Especially if it could be combined with granular commit/read
authentication by Apache discussed in an earlier thread--I'd love to be
able to set up a tag with public read permissions, where I could link to
the latest approved versions of documents (instead of HEAD)--and then
use mod_AuthLDAP to manage commit access for different groups to
different branches in the repository.
--
John Locke
http://freelock.com
Recently published: "Extend the reach of users' email with IMAP"
http://www.techrepublic.com/article_guest.jhtml?id=r00620030507jxl01.htm
Play sports? Check in at http://teamcheckin.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a permanent svn-specific URL syntax
Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
Ben Collins-Sussman wrote:
> But I've mentioned this before: I can't think of a reason *not* to
> implement this feature. Our canned repsonses are mainly blow-offs,
> and don't address the utility of the feature itself. I don't think
> anyone would argue that it's not useful.
Yes, it's useful, but I don't think it should be used carelessly.
For most uses an URL like
http://my-svn-repos/project/tags/version-1.32/the/source/file.c
is probably enough (and more clear to the end user, as it does not
advertise internal rev numbers, but external release numbers.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org