You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by SLOGEN <je...@slog.dk> on 2003/08/05 07:26:58 UTC
PROPOSAL: URL-syntax (Was: Re: Official revision syntax for Subversion
URLs)
Currently proposed methods for URL's of revisions have several flaws:
- they either make some files unnamable by the syntax, or require
escaping of certain caracters
- they make relative operations on URL's fail, (URL to "./foo" gives
you HEAD rev. of foo, not the same revision as you asked for this file)
- The "?" notation makes the results uncacheable (jf.
ftp://ftp.isi.edu/in-notes/rfc2616.txt)
I propose an alternate notation:
Add any revision-encoding to the repository path, example:
http://svn.foo/repository;1234/dir/file
The ";" could be whatever you like, just something unusual will be best.
Pros:
- It captures the exact philosophy behind subversion, that
repositories have revisions, not files.
- It allows _any_ file-names representable in URL notation
- It makes relative URL's work (moving to ./file2 gives you rev. 1234,
not HEAD)
- It's easy usable for scripts/cmd-line, no escaping
- HTTP allows caching of the resulting values
Cons:
- It disallows repositories with certain names, for example if we
choose the ";" you cannot have a repository directory named
".*;([0-9]+|HEAD)"
What's your thoughts?
--
Helge
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PROPOSAL: URL-syntax (Was: Re: Official revision syntax for
Subversion URLs)
Posted by Jack Repenning <jr...@collab.net>.
At 9:26 AM +0200 8/5/03, SLOGEN wrote:
>I propose an alternate notation:
>
>Add any revision-encoding to the repository path, example:
>
> http://svn.foo/repository;1234/dir/file
>
>The ";" could be whatever you like, just something unusual will be best.
>
>Pros:
>
> - It captures the exact philosophy behind subversion, that
>repositories have revisions, not files.
I like this part.
> - It allows _any_ file-names representable in URL notation
Well ... all you've done is move the point of incompatibility up to
the top. It still means some repository names can't be specified
without quoting or similar.
> - It makes relative URL's work (moving to ./file2 gives you rev.
>1234, not HEAD)
Again, only if the ../ trail does not pass through the root (the
point with the mark-up)
> - It's easily usable for scripts/cmd-line, no escaping
You lost me, here. So far as I can see, scripts and command lines are
sensitive to their own favorite characters no matter where in the
path they may be, and escaping is always required.
OTOH, this notation is easy for scripts in another way: it preserves
the "anonymously rooted subtree" structure. That is, the path inside
the work area is identically the path for this annotated URL
(assuming, of course, there have been no changes in the tree). It's
pretty common to script your way over the tree, and it's easier if
the revision info can be parked in a constant representing the
"other-version" repository, rather than interpolating it into each
string. For example:
find src -name \*.java |
while read javafile; do
svn diff http://svn.com/repo;123/$javafile \
http://svn.com/repo;456/$javafile
done
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PROPOSAL: URL-syntax (Was: Re: Official revision syntax for
Subversion URLs)
Posted by SLOGEN <je...@slog.dk>.
Daniel Patterson wrote:
> On Tue, 2003-08-05 at 17:33, Julian Reschke wrote:
>>>From: SLOGEN [mailto:jensen@slog.dk]
>>> - The "?" notation makes the results uncacheable (jf.
>>>ftp://ftp.isi.edu/in-notes/rfc2616.txt)
>>Section?
You got pinned there, It seems I'm not correct. My only "defence" is
that my knowledge of HTTP stems from 1.0-days, and practical experience.
I moved on from being a CGI programmer 5 years ago.
> 13.9 probably. However, HTTP/1.1 servers *may* indicate that URI's
> with the "?" character in them may be cached.
...
> We note one exception to this rule: since some applications have
> traditionally used GETs and HEADs with query URLs (those containing a
> "?" in the rel_path part) to perform operations with significant side
> effects, caches MUST NOT treat responses to such URIs as fresh unless
> the server provides an explicit expiration time. This specifically
> means that responses from HTTP/1.0 servers for such URIs SHOULD NOT
> be taken from a cache. See section 9.1.1 for related information.
Hmm.... that still doesn't help my claim, even though it suggests that
using "?" is generally a bad idea if you want people to cache the results.
I'm not really aware of the current situation on the "browser-market",
but a few years ago a main problem in CGI was to control caching
consistently on all browsers. IE and Netscape (and others) did different
stuff with the "?" notation, as well as "Cache-control:" and "Expires:"
headers.
Anyway, the major point is not whether caching occurs or not, that's up
to the client, I just want to increase chances of it.
The major point is, that adding the revision parameter to the repository
instead of the end-of-url seems to be a better way to express the
intentions.
--
Helge
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: PROPOSAL: URL-syntax (Was: Re: Official revision syntax for
Subversion URLs)
Posted by Daniel Patterson <da...@adaptiveinternational.com>.
On Tue, 2003-08-05 at 17:33, Julian Reschke wrote:
> > From: SLOGEN [mailto:jensen@slog.dk]
> > Sent: Tuesday, August 05, 2003 9:27 AM
> > To: Carey Evans
> > Cc: dev@subversion.tigris.org
> > Subject: PROPOSAL: URL-syntax (Was: Re: Official revision syntax for
> > Subversion URLs)
> >
> >
> > Currently proposed methods for URL's of revisions have several flaws:
> >
> > - they either make some files unnamable by the syntax, or require
> > escaping of certain caracters
> > - they make relative operations on URL's fail, (URL to "./foo" gives
> > you HEAD rev. of foo, not the same revision as you asked for this file)
> > - The "?" notation makes the results uncacheable (jf.
> > ftp://ftp.isi.edu/in-notes/rfc2616.txt)
>
> Section?
13.9 probably. However, HTTP/1.1 servers *may* indicate that URI's
with the "?" character in them may be cached.
--------------
13.9 Side Effects of GET and HEAD
Unless the origin server explicitly prohibits the caching of their
responses, the application of GET and HEAD methods to any resources
SHOULD NOT have side effects that would lead to erroneous behavior if
these responses are taken from a cache. They MAY still have side
effects, but a cache is not required to consider such side effects in
its caching decisions. Caches are always expected to observe an
origin server's explicit restrictions on caching.
We note one exception to this rule: since some applications have
traditionally used GETs and HEADs with query URLs (those containing a
"?" in the rel_path part) to perform operations with significant side
effects, caches MUST NOT treat responses to such URIs as fresh unless
the server provides an explicit expiration time. This specifically
means that responses from HTTP/1.0 servers for such URIs SHOULD NOT
be taken from a cache. See section 9.1.1 for related information.
---------------------------
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: PROPOSAL: URL-syntax (Was: Re: Official revision syntax for Subversion URLs)
Posted by Julian Reschke <ju...@gmx.de>.
> From: SLOGEN [mailto:jensen@slog.dk]
> Sent: Tuesday, August 05, 2003 9:27 AM
> To: Carey Evans
> Cc: dev@subversion.tigris.org
> Subject: PROPOSAL: URL-syntax (Was: Re: Official revision syntax for
> Subversion URLs)
>
>
> Currently proposed methods for URL's of revisions have several flaws:
>
> - they either make some files unnamable by the syntax, or require
> escaping of certain caracters
> - they make relative operations on URL's fail, (URL to "./foo" gives
> you HEAD rev. of foo, not the same revision as you asked for this file)
> - The "?" notation makes the results uncacheable (jf.
> ftp://ftp.isi.edu/in-notes/rfc2616.txt)
Section?
> ...
Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PROPOSAL: URL-syntax (Was: Re: Official revision syntax for Subversion URLs)
Posted by Russell Yanofsky <re...@columbia.edu>.
Branko Čibej wrote:
> Russell Yanofsky wrote:
>
>> Jack Repenning wrote:
>>
>>
>>> At 6:51 PM -0400 8/6/03, Russell Yanofsky wrote:
>>>
>>>
>>>> For example, say x/y/z was newly added in
>>>> revision 5 as a modified copy of x/z from revision 4. The url
>>>>
>>>> /x;5/y/z;4
>>>>
>>>> refers to the file located at x/y/z in revision 5, and retrieves
>>>> its contents from revision 4.
>>>>
>>>>
>>> OK, so I think you're assuming that SVN knows where that file was in
>>> revision 4--more precisely, which version of that file was the
>>> source of the "svn cp" that materialized the file in x;5. I don't
>>> think it does.
>>>
>>>
>>
>> No, it does. Whenever there's a new file revision that's a result of
>> a copy, subversion records the file revision that is the source of
>> the copy. I don't know/remember where it stores this information,
>> but I know it does report it through the svn_repos_get_logs()
>> function, which is used by ViewCVS to make links to old files.
>>
> Yes, but what's the point of it all? This would add a feature to the
> URLs that the Subversion storage model doesn't have. Makes no sense
> to me.
It just adds the ability to retrieve an old revision of a copied file
without having to know the file's original location. Regardless of whether
or not this is a useful feature, it's perfectly compatible with Subversion's
storage model.
You'd have to ask SLOGEN what the point of it all is. I just wanted to
answer Jack's questions about how it could work.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PROPOSAL: URL-syntax (Was: Re: Official revision syntax for
Subversion URLs)
Posted by Branko Čibej <br...@xbc.nu>.
Russell Yanofsky wrote:
>Jack Repenning wrote:
>
>
>>At 6:51 PM -0400 8/6/03, Russell Yanofsky wrote:
>>
>>
>>>For example, say x/y/z was newly added in
>>>revision 5 as a modified copy of x/z from revision 4. The url
>>>
>>> /x;5/y/z;4
>>>
>>>refers to the file located at x/y/z in revision 5, and retrieves its
>>>contents from revision 4.
>>>
>>>
>>OK, so I think you're assuming that SVN knows where that file was in
>>revision 4--more precisely, which version of that file was the source
>>of the "svn cp" that materialized the file in x;5. I don't think it
>>does.
>>
>>
>
>No, it does. Whenever there's a new file revision that's a result of a copy,
>subversion records the file revision that is the source of the copy. I don't
>know/remember where it stores this information, but I know it does report it
>through the svn_repos_get_logs() function, which is used by ViewCVS to make
>links to old files.
>
Yes, but what's the point of it all? This would add a feature to the
URLs that the Subversion storage model doesn't have. Makes no sense to me.
--
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
Re: PROPOSAL: URL-syntax (Was: Re: Official revision syntax for Subversion URLs)
Posted by Russell Yanofsky <re...@columbia.edu>.
Jack Repenning wrote:
> At 6:51 PM -0400 8/6/03, Russell Yanofsky wrote:
>> For example, say x/y/z was newly added in
>> revision 5 as a modified copy of x/z from revision 4. The url
>>
>> /x;5/y/z;4
>>
>> refers to the file located at x/y/z in revision 5, and retrieves its
>> contents from revision 4.
>
> OK, so I think you're assuming that SVN knows where that file was in
> revision 4--more precisely, which version of that file was the source
> of the "svn cp" that materialized the file in x;5. I don't think it
> does.
No, it does. Whenever there's a new file revision that's a result of a copy,
subversion records the file revision that is the source of the copy. I don't
know/remember where it stores this information, but I know it does report it
through the svn_repos_get_logs() function, which is used by ViewCVS to make
links to old files.
To be sure, I'm not saying that using this URL scheme is a good idea, just
that it could make sense and have some benefits. I'd be happy with any of
the URL schemes being discussed, except the @rev one which would restrict
file names or require new rules for escaping.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PROPOSAL: URL-syntax (Was: Re: Official revision syntax for
Subversion URLs)
Posted by Jack Repenning <jr...@collab.net>.
At 6:51 PM -0400 8/6/03, Russell Yanofsky wrote:
>For example, say x/y/z was newly added in
>revision 5 as a modified copy of x/z from revision 4. The url
>
> /x;5/y/z;4
>
>refers to the file located at x/y/z in revision 5, and retrieves its
>contents from revision 4.
OK, so I think you're assuming that SVN knows where that file was in
revision 4--more precisely, which version of that file was the source
of the "svn cp" that materialized the file in x;5. I don't think it
does.
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PROPOSAL: URL-syntax (Was: Re: Official revision syntax for Subversion URLs)
Posted by Russell Yanofsky <re...@columbia.edu>.
"Jack Repenning" <jr...@collab.net> wrote:
> At 3:00 PM -0400 8/6/03, Russell Yanofsky wrote:
> >Jack Repenning wrote:
> >> At 11:52 AM +0200 8/6/03, SLOGEN wrote:
> >>>
> >>> http://host/path/to/repos/x/y;rev=5/z;rev=4
> >>>
> >>> Which retrieves the stuff that's named z, as it was in rev 4 of what
> > >> is named x/y on HEAD, as it was in rev 5's.
> > >
> > > Which of
> > > the many versions present in revision 4 is wanted?
> >
> >The one that has been copied to x/y/ in revision 5.
>
>
> OK, so what are we doing with the "rev=4" information? If rev=5
> applies both to "the version of y of interest" and also "the version
> of z of interest", then this is just a single-revision,
> stick-it-anywhere scheme, isn't it?
No, even though having more than one number in a URL would be redundant,
both numbers would be used. For example, say x/y/z was newly added in
revision 5 as a modified copy of x/z from revision 4. The url
/x;5/y/z;4
refers to the file located at x/y/z in revision 5, and retrieves its
contents from revision 4. It would then be equivalent to:
/x;4/z
For ViewCVS, generating the first URL is easier than generating the second
URL because in the second case it has look up the file's original location
for the revision it is linking to, and in the first case it can use any
known location and just tack on a revision number.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PROPOSAL: URL-syntax (Was: Re: Official revision syntax for
Subversion URLs)
Posted by Jack Repenning <jr...@collab.net>.
At 3:00 PM -0400 8/6/03, Russell Yanofsky wrote:
>Jack Repenning wrote:
>> At 11:52 AM +0200 8/6/03, SLOGEN wrote:
>>>
>>> http://host/path/to/repos/x/y;rev=5/z;rev=4
>>>
>>> Which retrieves the stuff that's named z, as it was in rev 4 of what
> >> is named x/y on HEAD, as it was in rev 5's.
> >
> > Which of
> > the many versions present in revision 4 is wanted?
>
>The one that has been copied to x/y/ in revision 5.
OK, so what are we doing with the "rev=4" information? If rev=5
applies both to "the version of y of interest" and also "the version
of z of interest", then this is just a single-revision,
stick-it-anywhere scheme, isn't it?
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PROPOSAL: URL-syntax (Was: Re: Official revision syntax for Subversion URLs)
Posted by Russell Yanofsky <re...@columbia.edu>.
Jack Repenning wrote:
> At 11:52 AM +0200 8/6/03, SLOGEN wrote:
>>
>> http://host/path/to/repos/x/y;rev=5/z;rev=4
>>
>> Which retrieves the stuff that's named z, as it was in rev 4 of what
>> is named x/y on HEAD, as it was in rev 5's.
>>
>> Multiple ;rev='s would probably never be used, but they model the
>> exact possibilities that SVN offer, and in a _very_ sweet way!
>
> This sort of game is common in ClearCase, where a version is an
> attribute of an element, and the element has universal identity. But
> my poor brain can't quite figure out what it means in Subversion.
> You say "as it was in rev 5 of what is named x/y on HEAD" but that
> object may have had many versions in rev 4 -- one on each tag and
> branch.
>
> I think a Subversion version is only identified by the triple of:
> repo revision, path to the version of interest, and some unique
> identifier for what ClearCase calls the "element." What you've
> provided here doesn't quite reach that standard, does it? Which of
> the many versions present in revision 4 is wanted?
The one that has been copied to x/y/ in revision 5. Since subversion gives
each copy of a file a separate identifier (file revisions are identified by
a node id which is common to all copies and revisions of a file, a copy id
which is common to all revisions of a copy, and a revision number), this
should be possible to determine.
Having this type of url scheme would make it easier to support browsing of
copied/renamed files in ViewCVS (this currently doesn't work), even though
it isn't very intuitive IMO.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PROPOSAL: URL-syntax (Was: Re: Official revision syntax for
Subversion URLs)
Posted by Jack Repenning <jr...@collab.net>.
At 11:52 AM +0200 8/6/03, SLOGEN wrote:
>
> http://host/path/to/repos/x/y;rev=5/z;rev=4
>
>Which retrieves the stuff that's named z, as it was in rev 4 of what
>is named x/y on HEAD, as it was in rev 5's.
>
>Multiple ;rev='s would probably never be used, but they model the
>exact possibilities that SVN offer, and in a _very_ sweet way!
This sort of game is common in ClearCase, where a version is an
attribute of an element, and the element has universal identity. But
my poor brain can't quite figure out what it means in Subversion.
You say "as it was in rev 5 of what is named x/y on HEAD" but that
object may have had many versions in rev 4 -- one on each tag and
branch.
I think a Subversion version is only identified by the triple of:
repo revision, path to the version of interest, and some unique
identifier for what ClearCase calls the "element." What you've
provided here doesn't quite reach that standard, does it? Which of
the many versions present in revision 4 is wanted?
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PROPOSAL: URL-syntax (Was: Re: Official revision syntax for
Subversion URLs)
Posted by SLOGEN <je...@slog.dk>.
After some thought, I seem to have come to a realization about what is
the most proper solution.
We haven't realized that there actually is a difference between:
http://host/path/to/repos;rev=5/x
Which should retrieve x from the repository in revision 5, and
http://host/path/to/repos/x;rev=5
Which should retrive the thing that x means in HEAD, as that looked in
revision 5.
This means, actually that we should simply allow ;rev=[STUFF] on any path:
http://host/path/to/repos/x/y;rev=5/z;rev=4
Which retrieves the stuff that's named z, as it was in rev 4 of what is
named x/y on HEAD, as it was in rev 5's.
Multiple ;rev='s would probably never be used, but they model the exact
possibilities that SVN offer, and in a _very_ sweet way!
Now, the problem about the user's selection of where the ;rev should be
dissapears, since he can put it where he _means_, if he writes:
http://host/path/to/repos/~user;rev=6
He would get the ~user part of the repository as it looked in revision 6.
A way to get wayback-mode in the entire repository could be to use queries:
http://host/path/to/repos/~user?wayback-rev=8
that would redirect:
301 Permanently Moved
Location: http://host/path/to/repos;rev=8/~user
--
Helge
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PROPOSAL: URL-syntax
Posted by john <ma...@freelock.com>.
Jack Repenning wrote:
> At 8:06 AM +0300 8/6/03, Kalle Olavi Niemitalo wrote:
>
>> Erik Hülsmann <e....@gmx.net> writes:
>>
>>> http://subversion.kon.iki.fi/;109/nimiavaruus
>>>
>>> Would that not be acceptable?
>>
>>
>> Well, yes it would, provided that I could use %3b109 to refer to
>> a directory named ";109".
>
>
> Is the idea that this URL would be parsed by the client, and turned
> into a "regular" URL plus some protocol indication of the revision of
> interest -- basically, rewritten by the client into
> -r 109 http://subversion.kon.iki.fi/nimiavaruus
Perhaps short term, but I don't think this is desireable, because it
leads to far too many inconsistent implementations. I think it ought to
be dumped to the server as is--URL encode filenames with special
characters, but otherwise let the server do the work.
> If the URL is passed, then we create complications at the URL rewrite
> level, don't we? I'm not very smart about httpd configurations, but it
> seems tricky to write a rewrite rule that will handle arbitrary,
> optional stuff at this point.
To create a rewrite rule, you would have to know where to grab and where
to insert. But this is basically dependent on where in the URL the
repository is, something the Administrator would need to know. A simple
FAQ entry on the web site could provide examples of rewrite rules.
But the only time Apache should need to rewrite URLs is if you've moved
a repository.
>
> If, on the other hand, we put the revision marker just inside the
> repository (regardless of how deep that is into the URL), then we
> guarantee it reaches actual Subversion code, which can handle it
> consistently for all clients.
Yeah, but how does the client know what part of the path is inside the
repository? If you put the revision marker before the repository in the
URL, it would never reach Subversion, but get tossed by Apache (unless
there was a rewrite rule in place--inelegant).
I think we should allow revision markers at two places: at the
repository level (always included in URLs returned by subversion), and
at the end of the URL in a query string (which gets rewritten by
Subversion to put the revision marker at the repository level in the
URL). That can't be very hard to implement. I think it's not good to
allow it anywhere else--if you move a repository, you know where it came
from and where it went, so you can easily create an Apache rewrite rule
for that case. I don't see any benefit to making URLs that forgiving as
a general rule--the only reason I can think of is if you want to
actually obscure the location of the repository (which would just slow
somebody down a couple steps). That seems antithetical to some of the
benefits already brought up in this thread.
+1 to the idea of having a slightly different meaning to the query
string ?rev=xxx, where this version returns whatever this file was named
at the revision specified, and rewriting the returned URL to the
standard format with the revision marker embedded to the repository part
of the path.
Cheers,
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PROPOSAL: URL-syntax
Posted by Jack Repenning <jr...@collab.net>.
At 8:06 AM +0300 8/6/03, Kalle Olavi Niemitalo wrote:
>Erik Hülsmann <e....@gmx.net> writes:
>
>> http://subversion.kon.iki.fi/;109/nimiavaruus
>>
>> Would that not be acceptable?
>
>Well, yes it would, provided that I could use %3b109 to refer to
>a directory named ";109".
Is the idea that this URL would be parsed by the
client, and turned into a "regular" URL plus some
protocol indication of the revision of interest
-- basically, rewritten by the client into
-r 109 http://subversion.kon.iki.fi/nimiavaruus
Or is it the idea that the URL would pass to the
server side just as shown at top?
If the URL is parsed, then it doesn't help
generic clients (e.g., web browsers).
If the URL is passed, then we create
complications at the URL rewrite level, don't we?
I'm not very smart about httpd configurations,
but it seems tricky to write a rewrite rule that
will handle arbitrary, optional stuff at this
point.
If, on the other hand, we put the revision marker
just inside the repository (regardless of how
deep that is into the URL), then we guarantee it
reaches actual Subversion code, which can handle
it consistently for all clients.
I think. Don't we?
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PROPOSAL: URL-syntax
Posted by Kalle Olavi Niemitalo <ko...@iki.fi>.
Erik Hülsmann <e....@gmx.net> writes:
> http://subversion.kon.iki.fi/;109/nimiavaruus
>
> Would that not be acceptable?
Well, yes it would, provided that I could use %3b109 to refer to
a directory named ";109".
Inserting a path segment at the beginning like that seems a bit
weird though, but I suppose it won't actually cause any more
problems than altering the first segment would.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PROPOSAL: URL-syntax
Posted by Jerry Haltom <wa...@larvalstage.net>.
Could just use the ?rev=id that all other sorts of stuff uses. It's not
particularly intuitive, but is it suppose to be?
On Tue, 2003-08-05 at 13:43, Erik Hülsmann wrote:
> Hi Kalle,
>
> >SLOGEN <je...@slog.dk> writes:
> >
> >> Add any revision-encoding to the repository path, example:
> >>
> >> http://svn.foo/repository;1234/dir/file
> >
> >I have a Subversion repository directly at the root
> >of an Apache virtual host. Would I then use
> ><http://subversion.kon.iki.fi;109/nimiavaruus>
> >to refer to a file in revision 109 of the tree?
> >That syntax looks like it could well conflict with
> >future URI extensions for HTTP-over-tcpmux or such.
>
> The root of the http filespace is actually at
>
> http://subversion.kon.iki.fi/
>
> so the reference to your repository would become:
>
> http://subversion.kon.iki.fi/;109/nimiavaruus
>
> Would that not be acceptable?
>
> bye,
>
> Erik.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
--
Jerry Haltom
Feedback Plus, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PROPOSAL: URL-syntax
Posted by Erik Hülsmann <e....@gmx.net>.
Hi Kalle,
>SLOGEN <je...@slog.dk> writes:
>
>> Add any revision-encoding to the repository path, example:
>>
>> http://svn.foo/repository;1234/dir/file
>
>I have a Subversion repository directly at the root
>of an Apache virtual host. Would I then use
><http://subversion.kon.iki.fi;109/nimiavaruus>
>to refer to a file in revision 109 of the tree?
>That syntax looks like it could well conflict with
>future URI extensions for HTTP-over-tcpmux or such.
The root of the http filespace is actually at
http://subversion.kon.iki.fi/
so the reference to your repository would become:
http://subversion.kon.iki.fi/;109/nimiavaruus
Would that not be acceptable?
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PROPOSAL: URL-syntax
Posted by Kalle Olavi Niemitalo <ko...@iki.fi>.
SLOGEN <je...@slog.dk> writes:
> Add any revision-encoding to the repository path, example:
>
> http://svn.foo/repository;1234/dir/file
I have a Subversion repository directly at the root
of an Apache virtual host. Would I then use
<http://subversion.kon.iki.fi;109/nimiavaruus>
to refer to a file in revision 109 of the tree?
That syntax looks like it could well conflict with
future URI extensions for HTTP-over-tcpmux or such.
(The server is not in public DNS; don't bother trying.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org