You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jostein Christoffer Andersen <jo...@josander.net> on 2003/08/02 18:14:25 UTC
KDE's Subversion support are getting better :-)
Hi everybody,
It looks like KDE's Subversion support are more than buzzwords. The text
below are copied from http://members.shaw.ca/dkite/july252003.html
(KDE-CVS-Digest):
-----------------------------------------------------------------
Mickael Marchand committed a change to kdenonbeta/kio_svn
now you can get a file like this :
svn://svn.collab.net/repos/svn/trunk/README?rev=500 to get revision 500
of the file README :)
same with listDir coming soon ;)
-----------------------------------------------------------------
It's nice to see that Subversion shows up in more and more places :-)
Jostein
--
Jostein Chr. Andersen <jo...@josander.net> http://www.josander.net/
Public PGP Key:
Key: http://www.josander.net/pub_keys/jostein_josander.net.asc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Jack Repenning <jr...@collab.net>.
At 5:51 PM -0500 8/12/03, Russell Glaue wrote:
>Regardless, the URI format for LDAP is already invented, developed,
>documented and proven to work (proven to work for LDAP that is).
>Why not borrow the URI format.
Because LDAP and SVN store and retrieve completely different things,
and the operations we want to do with these URLs are completely
different?
The data values returned by LDAP do not contain embedded partial URLs
("relative hyperlinks"), nor is there any existing body of code we
can't change that thinks it knows how to combine the original URL and
these embedded URL-snippets into a new, working URL.
--
-==-
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: Official revision syntax for Subversion URLs
Posted by Russell Glaue <rg...@cait.org>.
Wow, what a big discussion on this topic.
I would like to suggest that the URL format for SVN to be followed is
to be the same format for LDAP URIs.
The format of the URI used in the famous open source Apache Web Server
is really good.
Here is an example LDAP URL:
ldap://ldap.apache.org/
dc=apache,dc=org?uid?sub?(&(objectClass=person)(objectclass=posixAccount
))
I recommend this not only because it would work, but because SVN could
then do filtering at the URL level.
Here is my suggested URL example format:
http://svn.apache.org/svn/repository/file/path/
?rev?(&(author=rglaue)(extension=.java))
I don't even know how useful this (file filtering) might be.
Regardless, the URI format for LDAP is already invented, developed,
documented and proven to work (proven to work for LDAP that is). Why
not borrow the URI format. Maybe even modify the URI format a little
to account for other subversion data.
It might be nice to connect to a LARGE subversion repository and only
see the files I authored; using the following URL:
http://svn.myHost.org/svn/myRepository/trunk/?4634?(author=rglaue)
Or see all the files in the repository for revision of 2934 using the
following URL:
http://svn.myHost.org/svn/myRepository/trunk/?2934
Maybe someone already suggested this in the last 100+ e-mails on this
topic, but it is my suggestion of what should be used.
-RG
On Monday, Aug 4, 2003, at 16:46 America/Chicago, kfogel@collab.net
wrote:
> [I've changed the name of this thread, so people will know what it's
> about.]
>
> Greg Hudson <gh...@MIT.EDU> writes:
>>>> and the URL syntax it invents is bogus
>>>> (/repos/svn/trunk/README may be a completely different resource
>>>> at two different revs).
>>
>> On Mon, 2003-08-04 at 15:49, kfogel@collab.net wrote:
>>> (I'm not sure I understand the problem behind Greg's
>>> last objection, but I'm sure he can explain it in more detail).
>>
>> We've talked about inventing a public URL syntax which includes a
>> revision number, and we ruled out using ?rev=revnum. See
>> <http://www.contactor.se/~dast/svn/archive-2003-06/0024.shtml>.
>
> Thanks for tracking that down.
>
> Well, we'll need *some* syntax for naming a path at a particular
> revision. I'm okay with the "path@rev" syntax the command line client
> has been using. It makes the class ".*@[0-9]+$" unavailable for
> paths, but a similar objection would apply to any other character.
>
> However, I have this feeling in the back of my mind that we've always
> been somewhat tentative about the '@' syntax... Why is that? Am I
> imagining things? Are we now ready to proclaim it the Official Way to
> specify a revision in a Subversion URL?
>
> Note that currently only the client interprets that syntax. If it's
> going to be used by other applications (such as KDE), we'll need to
> make the server aware of it as well. I don't see any reason why that
> would be hard, but maybe I just haven't thought it through enough? :-)
>
> -Karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Jan Braun <ja...@gmx.de>.
Hi,
cmpilato@collab.net wrote:
>
> We already have a quoting mechanism: URI encoding. As long as we
> choose a character which is required to be escaped by the r00lz of
> URIs, then when we see that character prefixing a revision indication,
> we know one of two things:
>
> a) the user is passing an invalid URI to the program, or
> b) the user is indication a revision as part of his URI
>
> If we default to (b), then we can fail gracefully when we attempt to
> valid that the "revision" portion is non-numeric, or doesn't match the
> strings "HEAD", "BASE", etc. If it just so happens that they have a
> real path which contains that character and a revision-looking thing,
> then we have a ready defense: "You didn't pass a valid URI, and the
> invalid URI you *did* pass just happened to look like one of our combo
> URI+revision strings."
Yes, but this makes URL+revision strings invalid URIs, by design.
You really want to specify the revision _within_ the URI.
Jan
---------------------------------------------------------------------
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
PROPOSAL: URL-syntax (Was: Re: Official revision syntax for Subversion
URLs)
Posted by SLOGEN <je...@slog.dk>.
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: Official revision syntax for Subversion URLs
Posted by Carey Evans <ca...@spamcop.net>.
cmpilato@collab.net writes:
> We already have a quoting mechanism: URI encoding. As long as we
> choose a character which is required to be escaped by the r00lz of
> URIs, then when we see that character prefixing a revision indication,
> we know one of two things:
>
> a) the user is passing an invalid URI to the program, or
> b) the user is indication a revision as part of his URI
There is a character that fits those criteria: the semicolon. It's
not used by much; I only know of its use by Java Servlets, which use
it for session tracking.
Something like http://example.com/repos/project/trunk/README;500 or
...;r=500 seems good to me.
--
"Hanging is too good for a man who makes puns; he should be drawn and quoted."
-- Fred Allen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by cm...@collab.net.
kfogel@collab.net writes:
> Heh, that's a cute solution.
>
> No matter what we choose, we're going to have to come up with a
> quoting or escaping mechanism of some sort.
We already have a quoting mechanism: URI encoding. As long as we
choose a character which is required to be escaped by the r00lz of
URIs, then when we see that character prefixing a revision indication,
we know one of two things:
a) the user is passing an invalid URI to the program, or
b) the user is indication a revision as part of his URI
If we default to (b), then we can fail gracefully when we attempt to
valid that the "revision" portion is non-numeric, or doesn't match the
strings "HEAD", "BASE", etc. If it just so happens that they have a
real path which contains that character and a revision-looking thing,
then we have a ready defense: "You didn't pass a valid URI, and the
invalid URI you *did* pass just happened to look like one of our combo
URI+revision strings."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Daniel Patterson <da...@adaptiveinternational.com>.
On Tue, 2003-08-05 at 14:25, Justin Erenkrantz wrote:
>
> Didn't we have this exact conversation a few months ago? Anyone remember what
> the consensus was? IIRC, all of the suggestions that have been made now were
> made then, too.
Yes we did. I think the concensus was not to do anything because
nobody could decide what colour the bikeshed should be.
I'll throw another colour into the palette: put the revision at
the root of the repository URL:
http://myserver/repos@124/path/to/file
This:
1) Avoids ambiguity on resouces within a revision tree
2) Doesn't need any special escaping/dodgy logic
3) More closely represents what the repository is actually
doing (shifting to a revision and finding a resource, not
the other way around).
Downsides:
1) It's not always clear (to the user) where to stick the
revision info in the URL.
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Jack Repenning <jr...@collab.net>.
At 11:27 PM -0500 8/4/03, Jeffrey Melloy wrote:
>Yes you could, the URL would just be http://myrepos/r1234/r1234
Which of those is the revision, and which is the file?
If there exist both a revision "r1234" and a revision "r2345", and
also files of those names (in all revisions), then we'd get different
revisions of different files, depending.
--
-==-
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: Official revision syntax for Subversion URLs
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, August 4, 2003 11:27 PM -0500 Jeffrey Melloy
<jm...@visualdistortion.org> wrote:
> Yes you could, the URL would just be http://myrepos/r1234/r1234
No, then, how do we represent HEAD?
/myrepos/HEAD/HEAD?
Um, no. Any clean solution should not force revnums upon the world. HEAD
should be implicit. And, I think it needs to be that way for WebDAV clients
to remain sane. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Jeffrey Melloy <jm...@visualdistortion.org>.
Yes you could, the URL would just be http://myrepos/r1234/r1234
On Monday, August 4, 2003, at 11:25 PM, Justin Erenkrantz wrote:
> --On Monday, August 4, 2003 9:02 PM -0700 Jack Repenning
> <jr...@collab.net> wrote:
>
>> At 9:25 AM +1000 8/5/03, Daniel Patterson wrote:
>>> Maybe not. The "/" character is already reserved, perhaps *it*
>>> could be used. The syntax isn't quite as obvious as using
>>> an @, but it avoids escapy-ness issues:
>>>
>>> http://my.server.com/repos/some/path/to/file/r1234
>>
>> Hmm ... and also
>> http://my.server.com/repos/some/path/to/directory/r1234?
>> Seems like this makes the logic to parse even more complicated.
>
> Then I couldn't have a file called 1234 or r1234 in that directory.
>
> Didn't we have this exact conversation a few months ago? Anyone
> remember what the consensus was? IIRC, all of the suggestions that
> have been made now were made then, too. -- justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, August 4, 2003 9:02 PM -0700 Jack Repenning
<jr...@collab.net> wrote:
> At 9:25 AM +1000 8/5/03, Daniel Patterson wrote:
>> Maybe not. The "/" character is already reserved, perhaps *it*
>> could be used. The syntax isn't quite as obvious as using
>> an @, but it avoids escapy-ness issues:
>>
>> http://my.server.com/repos/some/path/to/file/r1234
>
> Hmm ... and also http://my.server.com/repos/some/path/to/directory/r1234?
> Seems like this makes the logic to parse even more complicated.
Then I couldn't have a file called 1234 or r1234 in that directory.
Didn't we have this exact conversation a few months ago? Anyone remember what
the consensus was? IIRC, all of the suggestions that have been made now were
made then, too. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Jack Repenning <jr...@collab.net>.
At 9:25 AM +1000 8/5/03, Daniel Patterson wrote:
> Maybe not. The "/" character is already reserved, perhaps *it*
> could be used. The syntax isn't quite as obvious as using
> an @, but it avoids escapy-ness issues:
>
> http://my.server.com/repos/some/path/to/file/r1234
Hmm ... and also http://my.server.com/repos/some/path/to/directory/r1234?
Seems like this makes the logic to parse even more complicated.
--
-==-
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: Official revision syntax for Subversion URLs
Posted by Daniel Patterson <da...@adaptiveinternational.com>.
On Tue, 2003-08-05 at 08:38, kfogel@collab.net wrote:
> Heh, that's a cute solution.
>
> No matter what we choose, we're going to have to come up with a
> quoting or escaping mechanism of some sort. I haven't been able to
> think of a character that combines intuitive-rememberableness with
> unlikely-to-appear-at-end-of-path as well as "@" (Philip, remember
> that the @-sign has to appear at the end of your filename and be
> followed only by numbers, for it to be ambiguous. How many files like
> that do you have?)
Maybe not. The "/" character is already reserved, perhaps *it*
could be used. The syntax isn't quite as obvious as using
an @, but it avoids escapy-ness issues:
http://my.server.com/repos/some/path/to/file/r1234
(with or without the "r").
The logic is a bit unwieldy when you try and work out whether "r1234"
is talking about a resource or a revision, but I don't think it has
any ambiguous cases.
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Philip Martin <ph...@codematters.co.uk>.
kfogel@collab.net writes:
> (Philip, remember that the @-sign has to appear at the end of your
> filename and be followed only by numbers, for it to be ambiguous.
> How many files like that do you have?)
Two, but it's the same file twice, once in the source directory and
once in the installation directory. So it's probably not a big
problem, although at least one person (it's not my code) uses
filenames ending '@[0-9]+'.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> A potential answer here is to say that if you're dealing with a pathname
> which looks like path@rev, or a variant pathname which could be
> anything, stick "@HEAD" (or maybe just "@") at the end, and it's
> guaranteed to work.
>
> It's not the world's most satisfying answer, because it's extra gunk you
> have to put in commands or URLs just to avoid a potential corner case.
> But it's an option.
Heh, that's a cute solution.
No matter what we choose, we're going to have to come up with a
quoting or escaping mechanism of some sort. I haven't been able to
think of a character that combines intuitive-rememberableness with
unlikely-to-appear-at-end-of-path as well as "@" (Philip, remember
that the @-sign has to appear at the end of your filename and be
followed only by numbers, for it to be ambiguous. How many files like
that do you have?)
So although I certainly understand Philip's concerns, I'm still
leaning toward "@".
Will wait for more commentary (and/or a gotcha from Philip) before
calling for a vote, though.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2003-08-04 at 18:39, Philip Martin wrote:
> The obvious answer is that it makes it more difficult to deal with
> filenames that include '@'.
A potential answer here is to say that if you're dealing with a pathname
which looks like path@rev, or a variant pathname which could be
anything, stick "@HEAD" (or maybe just "@") at the end, and it's
guaranteed to work.
It's not the world's most satisfying answer, because it's extra gunk you
have to put in commands or URLs just to avoid a potential corner case.
But it's an option.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Branko Čibej <br...@xbc.nu>.
Jerry Haltom wrote:
>I'd just like to point out that & is a special character in bash as it
>is.
>
>If we use &rev=id, the url would have to be quoted anyways.
>
Yes. And if there's a file in the repository with ; (or &) in it, that
char would have to be URI-escaped on the command line. So what?
<rant>I'm sick and tired of people who proclaim that anything that makes
you type extra chars on the command line is unacceptable -- and I don't
mean just in this thread. If only they'd get together, they'd probably
have invented the Direct Brain Plug-In interface by now and removed the
need for _any_ typing at all. But no, that's too obvious...</rant>
>On Tue, 2003-08-05 at 19:41, Robert Spier wrote:
>
>
>>At Tue, 5 Aug 2003 19:20:22 -0500,
>>Florin Iucha wrote:
>>
>>
>>>[1 <text/plain; us-ascii (quoted-printable)>]
>>>On Tue, Aug 05, 2003 at 03:31:12PM -0700, Jack Repenning wrote:
>>>
>>>
>>>>At 2:00 PM -0700 8/5/03, Robert Spier wrote:
>>>>
>>>>
>>>>> ';' on a shell
>>>>> command line is slightly painful.
>>>>>
>>>>>
>>>>It is. But for the rest of the debate, we're slicing fine
>>>>distinctions between "virtually impossible" and "utterly impossible."
>>>>A little "slightly painful" is a positive relief!
>>>>
>>>>
>>>It is more than "slightly painful": the syntax will force quoting,
>>>so from the shell you will have to enter three characters.
>>>
>>>
>>Two, but that's sufficiently more than one.
>>
>> http://svnhost/blah/blah\;1234
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>>For additional commands, e-mail: dev-help@subversion.tigris.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
--
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: Official revision syntax for Subversion URLs
Posted by Jerry Haltom <wa...@larvalstage.net>.
I'd just like to point out that & is a special character in bash as it
is.
If we use &rev=id, the url would have to be quoted anyways.
On Tue, 2003-08-05 at 19:41, Robert Spier wrote:
> At Tue, 5 Aug 2003 19:20:22 -0500,
> Florin Iucha wrote:
> >
> > [1 <text/plain; us-ascii (quoted-printable)>]
> > On Tue, Aug 05, 2003 at 03:31:12PM -0700, Jack Repenning wrote:
> > > At 2:00 PM -0700 8/5/03, Robert Spier wrote:
> > > > ';' on a shell
> > > > command line is slightly painful.
> > > It is. But for the rest of the debate, we're slicing fine
> > > distinctions between "virtually impossible" and "utterly impossible."
> > > A little "slightly painful" is a positive relief!
> > It is more than "slightly painful": the syntax will force quoting,
> > so from the shell you will have to enter three characters.
>
> Two, but that's sufficiently more than one.
>
> http://svnhost/blah/blah\;1234
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Robert Spier <rs...@pobox.com>.
At Tue, 5 Aug 2003 19:20:22 -0500,
Florin Iucha wrote:
>
> [1 <text/plain; us-ascii (quoted-printable)>]
> On Tue, Aug 05, 2003 at 03:31:12PM -0700, Jack Repenning wrote:
> > At 2:00 PM -0700 8/5/03, Robert Spier wrote:
> > > ';' on a shell
> > > command line is slightly painful.
> > It is. But for the rest of the debate, we're slicing fine
> > distinctions between "virtually impossible" and "utterly impossible."
> > A little "slightly painful" is a positive relief!
> It is more than "slightly painful": the syntax will force quoting,
> so from the shell you will have to enter three characters.
Two, but that's sufficiently more than one.
http://svnhost/blah/blah\;1234
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Florin Iucha <fl...@iucha.net>.
On Tue, Aug 05, 2003 at 03:31:12PM -0700, Jack Repenning wrote:
> At 2:00 PM -0700 8/5/03, Robert Spier wrote:
> > ';' on a shell
> > command line is slightly painful.
>
> It is. But for the rest of the debate, we're slicing fine
> distinctions between "virtually impossible" and "utterly impossible."
> A little "slightly painful" is a positive relief!
It is more than "slightly painful": the syntax will force quoting,
so from the shell you will have to enter three characters.
florin
--
Don't question authority: they don't know it either!
Re: Official revision syntax for Subversion URLs
Posted by Jack Repenning <jr...@collab.net>.
At 2:00 PM -0700 8/5/03, Robert Spier wrote:
> ';' on a shell
> command line is slightly painful.
It is. But for the rest of the debate, we're slicing fine
distinctions between "virtually impossible" and "utterly impossible."
A little "slightly painful" is a positive relief!
--
-==-
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: Official revision syntax for Subversion URLs
Posted by Robert Spier <rs...@pobox.com>.
> This would seem to suggest that we could safely use ';' as the seperator, to
> delimit the file path from the revision segment.
Except,
one of Chris or Karl's goals (I don't remember which one wrote it)
was to have this be a unified representation, so it could be used
as an alternate to -r for the svn client as well. ';' on a shell
command line is slightly painful.
-R
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by John Peacock <jp...@rowman.com>.
kfogel@collab.net wrote:
> The problem with all such proposals (i.e., one that put the revision
> between the repository and the path-within-the-repository) is that it
> is impossible to construct such a URL automatically.
FWIW, the lightbulb in my head finally came on (perhaps somewhat dimly).
>
> In other words, given a regular URL -- one that does not specify any
> revision -- one cannot textually transform it into a URL that includes
> the revision, because one does not know where to insert the revision.
>
This pretty much guarantees that the only scheme which will work is something
appended the the regular URL. Consequently, the only question is what character
to use as the revision delimiter. According to RFC-2396,
> 3.3. Path Component
>
> The path component contains data, specific to the authority (or the
> scheme if there is no authority component), identifying the resource
> within the scope of that scheme and authority.
>
> path = [ abs_path | opaque_part ]
>
> path_segments = segment *( "/" segment )
> segment = *pchar *( ";" param )
> param = *pchar
>
> pchar = unreserved | escaped |
> ":" | "@" | "&" | "=" | "+" | "$" | ","
>
> The path may consist of a sequence of path segments separated by a
> single slash "/" character. Within a path segment, the characters
> "/", ";", "=", and "?" are reserved. Each path segment may include a
> sequence of parameters, indicated by the semicolon ";" character.
> The parameters are not significant to the parsing of relative
> references.
>
This would seem to suggest that we could safely use ';' as the seperator, to
delimit the file path from the revision segment.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Julian Foad <ju...@btopenworld.com>.
Karl Fogel wrote:
> The problem with all such proposals (i.e., one that put the revision
> between the repository and the path-within-the-repository) is that it
> is impossible to construct such a URL automatically.
>
> In other words, given a regular URL -- one that does not specify any
> revision -- one cannot textually transform it into a URL that includes
> the revision, because one does not know where to insert the revision.
Francois Beausoleil wrote:
> Probably an unacceptable workaround, but could SVN not require the repos
> root be rooted at some specific spot ? Such as requiring the last
> component of the repository contain a specific string ?
That could work. I think you mean: if the form of a "regular URL" was such that the division between repository and path-within-repository could always be identified, then it would be obvious where to insert a revision number, so the problem is solved. Of course it would be a bit awkward to change the existing URL format now, but, if it were so, would that not be a good solution? If so, we could then discuss whether it would really be worth changing over, and exactly what syntax to use.
This possibly ties in with a long-standing proposal to make the same distinction (between repository and path-within-rpository) in working copy administrative data.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by cm...@collab.net.
"Francois Beausoleil" <fb...@users.sourceforge.net> writes:
> Probably an unacceptable workaround, but could SVN not require the repos
> root be rooted at some specific spot ? Such as requiring the last
> component of the repository contain a specific string ?
/boot :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Francois Beausoleil <fb...@users.sourceforge.net>.
Probably an unacceptable workaround, but could SVN not require the repos
root be rooted at some specific spot ? Such as requiring the last
component of the repository contain a specific string ?
Just to start the discussion going ;)
Bye !
François
On 05 Aug 2003 12:17:15 -0500, kfogel@collab.net said:
> "Francois Beausoleil" <fb...@users.sourceforge.net> writes:
> > I believe that the http://svn/path/to/repos@XYZ/path/to/file is both
> > closer to reality and hides many internal details when browsing the
> > repository.
>
> I am going to keep repeating this until it's no longer necessary:
>
> The problem with all such proposals (i.e., one that put the revision
> between the repository and the path-within-the-repository) is that it
> is impossible to construct such a URL automatically.
>
> In other words, given a regular URL -- one that does not specify any
> revision -- one cannot textually transform it into a URL that includes
> the revision, because one does not know where to insert the revision.
>
> Thus, I think this family of syntaxes is doomed, at least until
> someone explains a) why this isn't a fatal flaw, or b) a workaround.
>
> -Karl
Developer of Java Gui Builder
http://jgb.sourceforge.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by kf...@collab.net.
"Francois Beausoleil" <fb...@users.sourceforge.net> writes:
> I believe that the http://svn/path/to/repos@XYZ/path/to/file is both
> closer to reality and hides many internal details when browsing the
> repository.
I am going to keep repeating this until it's no longer necessary:
The problem with all such proposals (i.e., one that put the revision
between the repository and the path-within-the-repository) is that it
is impossible to construct such a URL automatically.
In other words, given a regular URL -- one that does not specify any
revision -- one cannot textually transform it into a URL that includes
the revision, because one does not know where to insert the revision.
Thus, I think this family of syntaxes is doomed, at least until
someone explains a) why this isn't a fatal flaw, or b) a workaround.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Francois Beausoleil <fb...@users.sourceforge.net>.
I would like to express my opinion regarding this thread.
I believe that the http://svn/path/to/repos@XYZ/path/to/file is both
closer to reality and hides many internal details when browsing the
repository. On my development machine, I checkin vendor tarballs. These
often contain documentation in HTML format. I set svn:mime-type to
text/html, so that when I browse the repository, the server sends the
proper Content-Type and the browser displays documents. Then, I can
follow relative links inside the documentation, and everything "just
works".
If we were to change Subversion to require a ?rev=XYZ to be tacked onto
the ends of URLs, then relative browsing will not work anymore. The
query will be required.
As for the point that the @ character is reserved in URI, this is a very
valid point. I would have liked it to be used, as the @ sign can be
pronounced "at". So, the URL http://svn/path/to/repos@XYZ can be
pronounced "h-t-t-p-colon-slash-slash-svn-path-to-repos-at-XYZ".
The last time this discussion happened on the list, I was +1 on ?rev=XYZ,
but now, I am -1. I am +1 on repos@XYZ. We will have to find an
alternative character though. The semi-colon (;) was already proposed,
and could be a good choice. One thing though, this should not be
configurable. This way, all SVN servers will answer to the same syntax.
Another point, what about the command-line client ? Should the merge and
diff commands be changed so that they would accept the new syntax ? This
would mean that
svn merge http://svn/path/to/repos/path/to/branch@123
http://svn/path/to/repos/path/to/branch@HEAD
would become:
svn merge http://svn/path/to/repos@123/path/to/branch
http://svn/path/to/repos@HEAD/path/to/branch
This is just something else to think about.
Hope that helps !
François
Developer of Java Gui Builder
http://jgb.sourceforge.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Jack Repenning <jr...@collab.net>.
At 10:16 AM -0500 8/5/03, cmpilato@collab.net wrote:
>Sounds good to me. A question first, though. Does this mean that you
>cannot version path containing '@@' in their names under ClearCase?
No, there's no such restriction. If an object name ends in '@@',
then its history begins at "@@@@".
What it does mean is that scripts that depend on the @@ notation
might be fooled in such a case. For example, I've often written
scripts that found themselves wondering "is this file a versioned
object, or only some view-private thing?" An easy but not absolutely
foolproof test is
if [ -f $file ] && [ -d ${file}@@ ]
That is, if there's a file named "foo", then ClearCase (dynamic
views) will show the history as a hidden directory named "foo@@".
Inside that directory will be things like "foo@@/REL_1", a labelled
version of foo, and also things like
"foo@@/main/REL_1_BRANCH/PATCH_37/6", a specific version of foo, the
sixth on the patch-37 branch of the release-1 branch (which,
presumably, branched off of main so people could work on release-2).
For a real fun time, then, create a ClearCase file named "foo", and
also a clearcase subdirectory named "foo@@"! This is allowed, but
any subsequent consternation is on your own head.
Oh, and the actual "@@" is actually a configuration option, so if you
really need directories named "foo@@" you can have ClearCase use "++"
or "<><" or "antitisestablishmentarianism." I confess I've never
actually changed this option, so I'm not sure whether it applies to
the whole site, particular VOBs, particular client hosts, or only
individual views (there are all these levels of configurability).
But we here don't need to feel compelled to recreate ClearCase; it is
enough if we can blow CVS out of the water. For now!
--
-==-
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: Official revision syntax for Subversion URLs
Posted by Branko Čibej <br...@xbc.nu>.
Luke Blanshard wrote:
> Branko Čibej wrote:
>
>> Luke Blanshard wrote:
>>
>>> Seems to me we could have it both ways:
>>>
>>> http://host/some/path/leading/to/file.html;123
>>>
>>> ... for thing-at-the-end, or:
>>>
>>> http://host/some/path;123/leading/to/file.html
>>
>> I don't think we need this. Remember, it only makes sense to have _one_
>> explicit version number per path -- you can't request
>>
>> http://host/part;1/file;2
>>
>> because the revision number always identifies a whole tree.
>
> Yes, but putting it earlier in the URL means that suddenly we can use
> a browser to look at an HTML file with relative links at a particular
> version. That's an important part of the discussion here. So with
> the form:
>
> http://host/some/path;123/leading/to/file.html
>
> ... a relative link in this file to "../../images/brane.gif" becomes
>
> http://host/some/path;123/images/brane.gif
>
> ... so we see the old, embarassing picture, instead of the new
> replacement you've dropped in at HEAD.
Ah, good point, I hadn't thought about relative links.
--
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: Official revision syntax for Subversion URLs
Posted by Luke Blanshard <lu...@blanshard.us>.
Branko Čibej wrote:
>Luke Blanshard wrote:
>
>
>>Seems to me we could have it both ways:
>>
>> http://host/some/path/leading/to/file.html;123
>>
>>... for thing-at-the-end, or:
>>
>> http://host/some/path;123/leading/to/file.html
>>
>>...
>>
>>
>I don't think we need this. Remember, it only makes sense to have _one_
>explicit version number per path -- you can't request
>
> http://host/part;1/file;2
>
>because the revision number always identifies a whole tree.
>
Yes, but putting it earlier in the URL means that suddenly we can use a
browser to look at an HTML file with relative links at a particular
version. That's an important part of the discussion here. So with the
form:
http://host/some/path;123/leading/to/file.html
... a relative link in this file to "../../images/brane.gif" becomes
http://host/some/path;123/images/brane.gif
... so we see the old, embarassing picture, instead of the new
replacement you've dropped in at HEAD.
> Since this
>is the case, I think appending the revision number to the end of the URL
>seems to be the most natural way. And as ';' appears to be an URI
>separator that has the right semantics (i.e., it indicates a different
>resource), the URL;REV syntax is sane. We could also support URL;{date}...
>
>
Sure, good idea. But you should just support it anywhere within the
URL, to make it possible to give the relative filename references the
right meaning.
It's easy to deal with a second version spec in the same URL: just
declare the URL invalid. 404.
Luke
The purpose of having the
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Branko Čibej <br...@xbc.nu>.
Luke Blanshard wrote:
> kfogel@collab.net wrote:
>
>> All I'm saying is that thing-in-the-middle solutions are undesirable.
>> There remains the whole class of thing-at-the-end solutions, which is
>> what I'm assuming we'll end up with (perhaps with '@@' as separator,
>> perhaps something else).
>>
>>
> Seems to me we could have it both ways:
>
> http://host/some/path/leading/to/file.html;123
>
> ... for thing-at-the-end, or:
>
> http://host/some/path;123/leading/to/file.html
>
> ... for thing-in-the-middle. Note that we don't know or care whether
> /some/path is the root of the repository, it just has to be in the
> repository. The idea is that the revision number can appear at *any*
> component of the path.
I don't think we need this. Remember, it only makes sense to have _one_
explicit version number per path -- you can't request
http://host/part;1/file;2
because the revision number always identifies a whole tree. Since this
is the case, I think appending the revision number to the end of the URL
seems to be the most natural way. And as ';' appears to be an URI
separator that has the right semantics (i.e., it indicates a different
resource), the URL;REV syntax is sane. We could also support URL;{date}...
--
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: Official revision syntax for Subversion URLs
Posted by Luke Blanshard <lu...@blanshard.us>.
kfogel@collab.net wrote:
>All I'm saying is that thing-in-the-middle solutions are undesirable.
>There remains the whole class of thing-at-the-end solutions, which is
>what I'm assuming we'll end up with (perhaps with '@@' as separator,
>perhaps something else).
>
>
Seems to me we could have it both ways:
http://host/some/path/leading/to/file.html;123
... for thing-at-the-end, or:
http://host/some/path;123/leading/to/file.html
... for thing-in-the-middle. Note that we don't know or care whether
/some/path is the root of the repository, it just has to be in the
repository. The idea is that the revision number can appear at *any*
component of the path.
This provides simple at-the-end rules that will always work, and
in-the-middle rules for manually constructed URLs. And it conforms to
the rules for URLs, as best as I can tell.
I suppose we'd need to define what happens if two different numbers
appeared in the same path. How about "file not found"?
I think John Peacock proposed this earlier, actually.
Luke
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by kf...@collab.net.
Jack Repenning <jr...@collab.net> writes:
> Why?
>
> I see why it would be cooler to do it without contacting the repo, but
> I don't see an absolute necessity. Whatever we do with this URL, once
> we've composed it, is going to involve contacting the repo (isn't
> it?), so we're not enabling anything so grand as disconnected work.
> We're talking about a performance enhancement, I guess: save one
> server round-trip during the set-up, before we start into something
> that'll cost at least one more. Is that so crucial that we'd rather
> have no solution at all?
Oh, nobody's talking about "no solution at all".
All I'm saying is that thing-in-the-middle solutions are undesirable.
There remains the whole class of thing-at-the-end solutions, which is
what I'm assuming we'll end up with (perhaps with '@@' as separator,
perhaps something else).
I assumed that was implied, since such solutions have been widely
discussed in this thread all along. Sorry if that wasn't clear.
As for why constructability is important: Wow, it seems really obvious
to me, no offense, but I'll try to articulate it here. I don't think
I'm going to be able to do justice to how fundamentally important it
is, though.
When a user has a clear and simple concept in their head (such as "a
path at a revision"), then it's bad for an interface to put an
obstacle between the concept and its concrete expression. There will
be all sorts of circumstances in which people know they want a path at
a particular revision. To force them to make an extra round trip
merely in order to *construct the request* would be extremely
annoying.
The issue isn't the technical cost of the network round trip (although
that's bad too). The greater evil is extra round trip *between the
user and the interface*. The person knows what they want, clear as
day, yet they can't ask for it in one question -- instead, they need
two: first, ask for this other thing, then use it to ask for the thing
they originally wanted. An extra token has been inserted in their
life, for no good reason (since other solutions are available).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Jack Repenning <jr...@collab.net>.
At 12:10 PM -0500 8/5/03, kfogel@collab.net wrote:
> The point is to
>be able to construct a revision-specific URL *without* contacting the
>repository.
Why?
I see why it would be cooler to do it without contacting the repo,
but I don't see an absolute necessity. Whatever we do with this URL,
once we've composed it, is going to involve contacting the repo
(isn't it?), so we're not enabling anything so grand as disconnected
work. We're talking about a performance enhancement, I guess: save
one server round-trip during the set-up, before we start into
something that'll cost at least one more. Is that so crucial that
we'd rather have no solution at all?
--
-==-
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: Official revision syntax for Subversion URLs
Posted by kf...@collab.net.
Mickael Marchand <ma...@kde.org> writes:
> for arguments like "revnum" I am opened to suggestions and will follow your
> decision. I just choose an arbritary one for now to be able to get a
> revision from a URL.
> "?rev=revnum" looked nice to me. It would be great if svn-enabled servers
> could parse that. It would surely simplify client developers' life ;)
> note that we could also use ?rev=PREV for example (not only numbers), and also
> dates ...
Thanks for the reply! We're hashing out a syntax, and will get back
to you soon (within a couple of weeks, I think, if that's okay).
Feel free to participate in the thread if you want, of course -- but I
warn you, it's a jungle in there :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Mickael Marchand <ma...@kde.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
sorry, I had some mails trouble recently so it took me some time to answer.
to clarify some stuff about KDE's client, right now it's "prepre-alpha" and
only access remote "http://" svn servers. I plan to change the svn:// naming
to match the Subversion one. I should be able to support all "ra" in the same
kioslave.
For those of you who don't know KDE, a kioslave is an interface for a
protocol. For example, if you type : http://subversion.tigris.org/ in konqui
and press enter, it will start a "kio-job" to retrieve the web page using the
HTTP protocol. It is basically an asynchronous interface for access to a
local and/or remote filesystems (list, get, put, rmdir, mkdir, del, ...).
Each kioslave has one/many protocol assigned to : the http kioslave handles
http and https:// URLs for example. That also implies that another ioslave
cannot use the same protocol name.
I just don't know for the http:// thing since I can't use it for my kioslave
(for technical reasons I can't "add" it to the http-kioslave, and probably
some political reasons inside KDE if I ever fix the technicals one ;)
maybe I could use shttp://, shttps:// and svn:// which is a bit clearer and
avoid the naming conflict (for KDE). (There is also the "file://" access
which conflicts in KDE ...)
for arguments like "revnum" I am opened to suggestions and will follow your
decision. I just choose an arbritary one for now to be able to get a revision
from a URL.
"?rev=revnum" looked nice to me. It would be great if svn-enabled servers
could parse that. It would surely simplify client developers' life ;)
note that we could also use ?rev=PREV for example (not only numbers), and also
dates ...
using it in URLs is not a requirement for me, I can specify it elsewhere
(internally), but I find great for users to be able to retrieve the revision
they want directly in konqueror and I think this is something we should have
at the end (client or server side).
It is on another side really hard to add a "text entry field" for people to
input the revision number at the kioslave level. But the kioslave is just a
low level protocol for KDE. The goal is to have it used by other applications
like gideon and cervisia where you should have these kind of "text field" and
advanced features. The kioslave can (as said before) get the revnum through
internal/hidden communication (not the URL itself).
I hope it's a bit clear :)
Cheers,
Mik
Le Tuesday 05 August 2003 23:30, kfogel@collab.net a écrit :
> Okay, I'm beginning to think we don't urgently need to solve this
> problem (a sentiment others have already expressed).
>
> The original motivation for this thread was that Mickael Marchand
> invented a "path?rev" syntax for Subversion URLs, presumably entered
> into text fields in KDE.
>
> We should discourage ad hoc syntax creation, so that users don't get
> misled into thinking there's a cross-environment standard where there
> isn't one. (Hence I've CC'd Mickael on this mail.)
>
> But it's not necessarily urgent that we choose a standard before SVN
> 1.0 -- sure, it would be nice, but I can see it's going to be a rather
> long discussion, and we don't know how hard it will be to implement on
> the server side even once we know the syntax.
>
> So Mickael, can you arrange the interface in some other way -- either
> don't offer specific revision functionality, or put the revision
> number in a separate text field? That solves the "creeping standard"
> problem; we can discuss longer-term solutions on the Subversion dev
> list at our no-doubt-copious leisure.
>
> -Karl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/MDY6yOYzc4nQ8j0RAvweAJ417hZ7J9ye2qnPm5O5i9gxFDe6FgCdFxTo
DW5szBZ52ReY8TA5m4wUjAY=
=fDwA
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by David Waite <ma...@akuma.org>.
I'll throw another bit into the fire - if the project accept my solution
(redirect to the proper 'internal' URL when a query "svn.revision=xxx"
is seen), I'll let you assign the issue to me ;-)
If the internal repository URLs change in the future, we can just update
the redirect logic later.
-David Waite
kfogel@collab.net wrote:
>Okay, I'm beginning to think we don't urgently need to solve this
>problem (a sentiment others have already expressed).
>
>The original motivation for this thread was that Mickael Marchand
>invented a "path?rev" syntax for Subversion URLs, presumably entered
>into text fields in KDE.
>
>We should discourage ad hoc syntax creation, so that users don't get
>misled into thinking there's a cross-environment standard where there
>isn't one. (Hence I've CC'd Mickael on this mail.)
>
>But it's not necessarily urgent that we choose a standard before SVN
>1.0 -- sure, it would be nice, but I can see it's going to be a rather
>long discussion, and we don't know how hard it will be to implement on
>the server side even once we know the syntax.
>
>So Mickael, can you arrange the interface in some other way -- either
>don't offer specific revision functionality, or put the revision
>number in a separate text field? That solves the "creeping standard"
>problem; we can discuss longer-term solutions on the Subversion dev
>list at our no-doubt-copious leisure.
>
>-Karl
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by kf...@collab.net.
John Locke <ma...@freelock.com> writes:
> Karl, you said earlier in this thread you wanted to call a vote soon. In
> the end, it doesn't matter that much exactly which syntax Subversion
> uses, but it seems critical (to me) that a syntax is defined as early as
> possible. Seems worth holding a vote and being done with the issue--if
> not, it'll just keep coming back...
Yeah, you're right, thanks for being persistent. We shouldn't abandon
this problem, we should solve it, at least to the point of publishing
a standard for Mickael to implement (even if our server doesn't
support it until later).
However, I'd like to let the thread stabilize some more before
initiating a vote. People have already made various useful and
unexpected points; there may be more of that before we're done. When
it's slowed down, I'll comb the entire thread and try to boil down the
concrete proposals, and put together a vote sheet.
And now, I'm going to just sit out and lurk for a bit... :-)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by John Locke <ma...@freelock.com>.
On Tue, 2003-08-05 at 14:30, kfogel@collab.net wrote:
> Okay, I'm beginning to think we don't urgently need to solve this
> problem (a sentiment others have already expressed).
>
Hmm. I respectfully disagree. You're having people external to this
group inventing protocols--Mickael is (hopefully) just the first of many
trying to make an integrated user experience. I think it's important to
nail down your basic URL schema early, before it spins out of your
hands...
> The original motivation for this thread was that Mickael Marchand
> invented a "path?rev" syntax for Subversion URLs, presumably entered
> into text fields in KDE.
>
I'm guessing that what Mickael is implementing can be entered directly
in the address bar of Konqueror--or any Open/Save dialog box in any KDE
application. No extra text fields available.
In KDE 3.1, you can copy files via SSH using the (KDE invented) fish://
protocol. It's very useful, and cool! It's a very simple way to make
secure file transfers to a computer running an SSH daemon--drag and
drop. There's also an IMAP:// protocol to browse an IMAP email server,
another for POP... all in all, I'm finding KDE to be a great way to get
to just about anything in hurry, just by typing a URL. Kudos to Mickael
for some great features!
> We should discourage ad hoc syntax creation, so that users don't get
> misled into thinking there's a cross-environment standard where there
> isn't one. (Hence I've CC'd Mickael on this mail.)
>
Agreed--that's why this should be decided sooner, by this group, rather
than later.
> But it's not necessarily urgent that we choose a standard before SVN
> 1.0 -- sure, it would be nice, but I can see it's going to be a rather
> long discussion, and we don't know how hard it will be to implement on
> the server side even once we know the syntax.
>
Seems to me the important thing is to define the syntax now, so that
anybody wanting to implement it doesn't go off and create their own
solutions while waiting for this. For example, early in this thread, it
was mentioned that the KDE protocol would be svn://. You've already
created a scheme for allowing different transports to the svnserver--
svn+ssh:// being the prime example. Seems that this could easily be
extended to be svn+http://, svn+https://, and svn+file:// to provide a
complete protocol scheme that can be typed from an address bar--and
furthermore, these are the schemes we should encourage KDE (and others)
to use, instead of redefining svn://.
Karl, you said earlier in this thread you wanted to call a vote soon. In
the end, it doesn't matter that much exactly which syntax Subversion
uses, but it seems critical (to me) that a syntax is defined as early as
possible. Seems worth holding a vote and being done with the issue--if
not, it'll just keep coming back...
--John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Official revision syntax for Subversion URLs
Posted by Sander Striker <st...@apache.org>.
> From: kfogel@newton.ch.collab.net [mailto:kfogel@newton.ch.collab.net]On
> Behalf Of kfogel@collab.net
> Sent: Tuesday, August 05, 2003 11:31 PM
> Okay, I'm beginning to think we don't urgently need to solve this
> problem (a sentiment others have already expressed).
Indeed. +1 for tabling this one once again. This topic leads
to way too much discussion at this point. I think we have other
things to see to that are more urgent.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by kf...@collab.net.
Okay, I'm beginning to think we don't urgently need to solve this
problem (a sentiment others have already expressed).
The original motivation for this thread was that Mickael Marchand
invented a "path?rev" syntax for Subversion URLs, presumably entered
into text fields in KDE.
We should discourage ad hoc syntax creation, so that users don't get
misled into thinking there's a cross-environment standard where there
isn't one. (Hence I've CC'd Mickael on this mail.)
But it's not necessarily urgent that we choose a standard before SVN
1.0 -- sure, it would be nice, but I can see it's going to be a rather
long discussion, and we don't know how hard it will be to implement on
the server side even once we know the syntax.
So Mickael, can you arrange the interface in some other way -- either
don't offer specific revision functionality, or put the revision
number in a separate text field? That solves the "creeping standard"
problem; we can discuss longer-term solutions on the Subversion dev
list at our no-doubt-copious leisure.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by John Peacock <jp...@rowman.com>.
SLOGEN wrote:
>
> Wouldn't http://slog.dk/~jensen/x;y.html and
> http://slog.dk/~jensen/x.html do for testing?
>
Except that those are the wrong form. The semicolon part has to appear at the
end, after the file extension:
http://slog.dk/~jensen/y.html;x
and just guessing from what was being displayed with your example, that's not
going to work. However, it did give me an idea:
The ';revision' has to be applied to the path, not the file, in order to be
considered part of the base URL for browser purposes, hence this:
http://slog.dk/~jensen;x/y.html
should correctly construct relative URL's, and all of these could be considered
equivalent, though only the last would be normalized:
http://slog.dk/~jensen;x/deeper/and/deeper/y.html
http://slog.dk/~jensen/deeper;x/and/deeper/y.html
http://slog.dk/~jensen/deeper/and;x/deeper/y.html
http://slog.dk/~jensen/deeper/and/deeper;x/y.html
The server would need to extract the revision from the URL prior to making up
the path/target.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by SLOGEN <je...@slog.dk>.
John Peacock wrote:
> Wow! You expect to be able to browse a subversion repository based on
> the links contained in files /stored/ in that repository??? I can see
> why it would be nice,
It works pretty nice (on HEAD) already, also with links to .pdf files
and stuff that is checked in.
> but I can also see that it is asking an awful lot
> of a fairly simple syntax.
Yes, that is a bit of a problem :)
> If what the browser considers the base URL contains the semicolon, will
> all relative links constructed from that URL also contain the semicolon,
> in the appropriate place? I have no idea, and I'm not even sure I know
> how to test it.
Wouldn't http://slog.dk/~jensen/x;y.html and
http://slog.dk/~jensen/x.html do for testing?
--
Helge>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Jack Repenning <jr...@collab.net>.
At 3:06 PM -0400 8/5/03, John Peacock wrote:
>
>Wow! You expect to be able to browse a subversion repository based
>on the links contained in files /stored/ in that repository???
Yes.
--
-==-
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: Official revision syntax for Subversion URLs
Posted by John Peacock <jp...@rowman.com>.
Jack Repenning wrote:
> It has links. Within the file itself, they say things like <href
> a="../helpers/foo.html">. If we got here via a rev-123 link, then it's
> fair to assume that rev 123 also includes ../helpers/foo.html. But it's
> not at all safe to assume that HEAD has one, or that it has the expected
> contents even if it does exist. So clicking on this link--whose text is
> a committed part of the versioned object--should carry forward the
> revision qualifications.
Wow! You expect to be able to browse a subversion repository based on the links
contained in files /stored/ in that repository??? I can see why it would be
nice, but I can also see that it is asking an awful lot of a fairly simple syntax.
If what the browser considers the base URL contains the semicolon, will all
relative links constructed from that URL also contain the semicolon, in the
appropriate place? I have no idea, and I'm not even sure I know how to test it.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Jack Repenning <jr...@collab.net>.
At 2:40 PM -0400 8/5/03, John Peacock wrote:
>Greg Hudson wrote:
>
>>Anything we stick at the end won't work with relative browsing.
>
>Can you explain that piece to me again?
Not sure if this is what Greg meant, but what I think of when I say
what he said is ...
Suppose we're storing HTML documents in Subversion. Suppose we use a
web browser to browse the repo (via WebDAV, or any of the other
arrangements that display within a browser and support what I'm about
to do). Suppose we don't stop with the nice little directory
listings, but actually click on a file name.
Voila! We see a web page. Cool.
It has links. Within the file itself, they say things like <href
a="../helpers/foo.html">. If we got here via a rev-123 link, then
it's fair to assume that rev 123 also includes ../helpers/foo.html.
But it's not at all safe to assume that HEAD has one, or that it has
the expected contents even if it does exist. So clicking on this
link--whose text is a committed part of the versioned object--should
carry forward the revision qualifications.
http://host/blah/blah/blah?query stuff doesn't carry the "query"
around like this.
http://host/blah/blah;revision/blah/blah/blah does. Doesn'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: Official revision syntax for Subversion URLs
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> Anything we stick at the end won't work with relative browsing.
Can you explain that piece to me again? Any browsing is going to be mediated by
some other system, be it TortoiseSVN, ViewCVS, or raw WebDAV. Since that tool
would have to be enabled to support this in the first place, they could also be
enhanced to maintain that information.
For example, the WebDAV interface currently returns links that look like this:
<a href="doc/">doc/</a>
If the user requested a specific revision of the that directory, the relative
link could easily look this:
<a href="doc/;2345">doc/</a>
and if the user clicked on that link, all links generated on the next page would
automatically have the ';2345' appended like this:
<a href="README;2345">README</a>
It would be nicer if the WebDAV interface would permit browsing changed
revisions on a specific file, but ViewCVS works fine in this respect...
Am I missing something?
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
John Peacock wrote:
> Greg Hudson wrote:
>
>> Jack described it well enough in:
>>
>> http://www.contactor.se/~dast/svn/archive-2003-08/0231.shtml
>>
>
> http://svn.rlpgbooks.com/test;1/Index.html
>
> Notice that the URL's as generated from the relative links include the
> semicolon and revision, as required.
>
> As an added bonus, VMS has had a versioned filesystem since the
> beginning of time, and it uses a semicolon followed by the revision
> number. So all of the VMS people will be instantly comfortable. :~)
I told myself I was going to stay out of this discussion, but I must
say, as a person who does use VMS from time to time, I would find using
the semicolon here quite reasonable.
(For the curious, my second choice at this point would be a single @, it
seems considerably more readable than @@, and if you need to version
files with @number in them, using a trailing @ seems like a reasonable
approach to me.)
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> Jack described it well enough in:
>
> http://www.contactor.se/~dast/svn/archive-2003-08/0231.shtml
>
http://svn.rlpgbooks.com/test;1/Index.html
Notice that the URL's as generated from the relative links include the semicolon
and revision, as required.
As an added bonus, VMS has had a versioned filesystem since the beginning of
time, and it uses a semicolon followed by the revision number. So all of the
VMS people will be instantly comfortable. :~)
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-08-05 at 16:37, Jack Repenning wrote:
> If I point an actual SVN client at file:///repo/blah/blah, the actual
> client's knowledge of WebDAV is no help, because the URL I've given
> it does not pass through a WebDAV server. Indeed, I might not even
> have mod_dav_svn set up at this site.
Uh, sure, but that's irrelevant.
If what you want is an HTTP URL to hand to people for that path in that
repository at a particular revision, you're sunk anyway; you have to
know whether there's a web server running and how it's configured before
you can produce one of those, no matter what we do in this conversation.
If what you want is that path in that repository at a particular
revision, you don't need to construct a URL; you use the appropriate
Subversion mechanism. I said "it can use DeltaV" before because we were
talking about HTTP URLs, but of course there are equivalent mechanisms
for file:// and svn://.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Jack Repenning <jr...@collab.net>.
At 4:24 PM -0400 8/5/03, Greg Hudson wrote:
>On Tue, 2003-08-05 at 16:20, Jack Repenning wrote:
>> At 4:09 PM -0400 8/5/03, Greg Hudson wrote:
>> >I'll observe that an actual svn client doesn't need to know how to add a
>> >rev to an HTTP URL; it can use DeltaV and do it right.
>>
>> Well, not if the user provided it with some other URL schema.
>
>I have no clue what you mean by this statement. Can you rephrase it?
Sorry ...
If I point an actual SVN client at file:///repo/blah/blah, the actual
client's knowledge of WebDAV is no help, because the URL I've given
it does not pass through a WebDAV server. Indeed, I might not even
have mod_dav_svn set up at this site.
I think the same can be said for svn://host/repo/blah/blah, can'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: Official revision syntax for Subversion URLs
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-08-05 at 16:20, Jack Repenning wrote:
> At 4:09 PM -0400 8/5/03, Greg Hudson wrote:
> >I'll observe that an actual svn client doesn't need to know how to add a
> >rev to an HTTP URL; it can use DeltaV and do it right.
>
> Well, not if the user provided it with some other URL schema.
I have no clue what you mean by this statement. Can you rephrase it?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Jack Repenning <jr...@collab.net>.
At 4:09 PM -0400 8/5/03, Greg Hudson wrote:
>I'll observe that an actual svn client doesn't need to know how to add a
>rev to an HTTP URL; it can use DeltaV and do it right.
Well, not if the user provided it with some other URL schema.
--
-==-
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: Official revision syntax for Subversion URLs
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-08-05 at 14:09, kfogel@collab.net wrote:
> Greg Hudson <gh...@MIT.EDU> writes:
> > Well, this is a problem, then. Anything we stick at the end won't work
> > with relative browsing. Anything we stick in the middle won't allow
> > uninformed textual transforms.
>
> Sorry -- how does that first part work? How do things at the end
> prevent relative browsing? Maybe I just don't know what you mean by
> "relative browsing".
Jack described it well enough in:
http://www.contactor.se/~dast/svn/archive-2003-08/0231.shtml
(Helge described a third option, putting the rev before the repos path.
But I think that's a non-starter from Apache's point of view.)
I'll observe that an actual svn client doesn't need to know how to add a
rev to an HTTP URL; it can use DeltaV and do it right. So I don't know
why it's so important that it should be doable automatically.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> Well, this is a problem, then. Anything we stick at the end won't work
> with relative browsing. Anything we stick in the middle won't allow
> uninformed textual transforms.
Sorry -- how does that first part work? How do things at the end
prevent relative browsing? Maybe I just don't know what you mean by
"relative browsing".
I was thinking the thing-on-the-end class of solutions were looking
the best (or least bad) so far...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-08-05 at 13:10, kfogel@collab.net wrote:
> The point is to be able to construct a revision-specific URL
> *without* contacting the repository. In other words, you just
> take a regular URL and apply a textual transformation to it.
> A proposal that doesn't satisfy this criterion is going to get -1'd
> very quickly, I'm sure.
Well, this is a problem, then. Anything we stick at the end won't work
with relative browsing. Anything we stick in the middle won't allow
uninformed textual transforms.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by kf...@collab.net.
John Peacock <jp...@rowman.com> writes:
> Point taken. But, how often are users going to be expected to go
> spelunking through old revisions without the crutch of a tool like
> viewcvs or TortoiseSVN?
??? Uh, all the time. What makes you think they wouldn't?
The URL syntax must work as well for the command line client as it
does for GUIs. Many people will happily script the command line
client before picking up a GUI. Nothing wrong with GUIs -- just some
people do things another way.
> Aren't tools with "direct" access to the
> repository able to pull out the root path? If not, then I can see the
> dilemma.
The command line client has the same direct access to the repository
as any other tool, but that isn't the point anyway. The point is to
be able to construct a revision-specific URL *without* contacting the
repository. In other words, you just take a regular URL and apply a
textual transformation to it.
A proposal that doesn't satisfy this criterion is going to get -1'd
very quickly, I'm sure.
> If the syntax is awkward for users without knowledge of the underlying
> repos structure, how much of a handicap is that if the more common
> tools can hide that? Perhaps just having something that makes sense
> to implement (which the tools can easily handle) is more important
> than having it dead simple for endusers to cobble together manually?
We're talking about a URL syntax here. If a human can't construct it,
there's little point in the tool doing it for them :-).
Look at it this way: if we were going to depend on the tool anyway, we
wouldn't need this new URL syntax -- we'd just have a separate text
field for the revision (for GUIs), or a separate option+argument (for
the command line client), as we can already have today.
Getting away from such tool-specific interface dependencies is the
whole purpose of this discussion.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Julian Foad <ju...@btopenworld.com>.
John Locke wrote:
> I'm thinking along David's lines here--redirecting to a URL that
> includes the repository revision:
...
> Make the version fragment (after the semicolon) optional on the request,
> but ALWAYS return at least the semicolon in the response. For the HEAD
> revision, you can ask for:
>
> http://base.url/whatever/path/to/repos/path/to/file.ext
>
> And you get:
>
> http://base.url/whatever/path/to/repos;/path/to/file.ext
Furthermore, this could be just a backward-compatibility mechanism to help transition from the current status quo to a new URL syntax in which a semicolon is required between the repository and the path within it. In that new world, anyone accessing a Subversion repository by HTTP will already see where to insert a revision number.
There are other benefits to being clear about where your repository is, such as the "understanding what you are doing" class of arguments. As I said in another reply, this possibly ties in with a long-standing proposal to make the same distinction in working copy administrative data.
I can't see any problems with always having such a separator in a Subversion URL.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by John Locke <ma...@freelock.com>.
On Tue, 2003-08-05 at 15:37, Jack Repenning wrote:
> At 3:00 PM -0700 8/5/03, John Locke wrote:
> >I think this is a very neat solution (redirecting to the correct
> >version), and what is particularly nice about it is that (a) can be done
> >(I think) without any changes to Subversion whatsoever, using an Apache
> >mod_rewrite rule.
>
> This seems like a *dis*advantage to me. It complicates the
> webmeister's life. Some will do it, some won't bother, some will
> take it as inspiration to do something even more cleverer. Chaos!
> Anarchy! Just the sort of "needless creativity" architecture is
> meant to forestall.
Yeah, you're right. Better to implement in Subversion.
But... here's another suggestion:
If this group decides upon a standard, and PUBLISHES it to the web site
as THE CORRECT URL SCHEME to use to access versions in the repository,
actual implementation could be put off until later--people could then go
ahead and build client applications to use the defined standard, and use
Apache rewriting to get them to work until they're implemented in
Subversion.
Cheers,
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Jack Repenning <jr...@collab.net>.
At 3:00 PM -0700 8/5/03, John Locke wrote:
>I think this is a very neat solution (redirecting to the correct
>version), and what is particularly nice about it is that (a) can be done
>(I think) without any changes to Subversion whatsoever, using an Apache
>mod_rewrite rule.
This seems like a *dis*advantage to me. It complicates the
webmeister's life. Some will do it, some won't bother, some will
take it as inspiration to do something even more cleverer. Chaos!
Anarchy! Just the sort of "needless creativity" architecture is
meant to forestall.
--
-==-
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: Official revision syntax for Subversion URLs
Posted by John Locke <ma...@freelock.com>.
I'm thinking along David's lines here--redirecting to a URL that
includes the repository revision:
On Tue, 2003-08-05 at 14:35, David Waite wrote:
> I would like to toss in another potential solution :-)
>
> a. We allow users to access the repository with a query segment
> (/repos/file?svn.revision=1234 or whatever)
> b. The repository redirects them to a path of a form like /repos/@1234/file
> c. The user agent shows that particular content.
>
> The user does not need to know the repository structure in order to get
> a particular revision, and the repository does not need to rewrite
> content in order for relative links to work. The repository can also
> keep whatever its existing syntax for revisions, although it might be
> desirable to change it to something which is documented and
> user-understood (like the @rev syntax above). This still requires a
> network round-trip - although, I think it could be a configuration
> option to just serve the file at the original query'd URL for GET requests.
>
I think this is a very neat solution (redirecting to the correct
version), and what is particularly nice about it is that (a) can be done
(I think) without any changes to Subversion whatsoever, using an Apache
mod_rewrite rule. Of course, the Apache administrator would have to know
the real location of the repository... and would need to get added to
Subversion for svn:// support...
I vote for the semicolon added to the repository URL:
http://base.url/whatever/path/to/repos;234/path/to/file.ext
What I'll add to this discussion, perhaps may not be desireable, but
it's an idea, anyway:
Make the version fragment (after the semicolon) optional on the request,
but ALWAYS return at least the semicolon in the response. For the HEAD
revision, you can ask for:
http://base.url/whatever/path/to/repos/path/to/file.ext
And you get:
http://base.url/whatever/path/to/repos;/path/to/file.ext
with a semicolon added to whichever part of the path identifies the
repository. If the repository is at the base of a virtual path, you
might get:
http://base.url/;/path/to/file.ext
back... and of course you can specify any repository version by simply
adding it after the semicolon.
Seems to me a solution along these lines addresses all the concerns in
this message head: you can browse in "way-back" mode, it's backwards
compatible, for scripting you can ask for a file appending the query
"?rev=234" (or equivalent) and parse the returned header to find the
semicolon without an extra trip to the server.
--
John Locke
http://freelock.com
Recently published: "Complete the e-mail set up: User accounts, DNS, and more"
http://www.techrepublic.com/article_guest.jhtml?id=r00620030617jxl01.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: Official revision syntax for Subversion URLs
Posted by David Waite <ma...@akuma.org>.
I would like to toss in another potential solution :-)
a. We allow users to access the repository with a query segment
(/repos/file?svn.revision=1234 or whatever)
b. The repository redirects them to a path of a form like /repos/@1234/file
c. The user agent shows that particular content.
The user does not need to know the repository structure in order to get
a particular revision, and the repository does not need to rewrite
content in order for relative links to work. The repository can also
keep whatever its existing syntax for revisions, although it might be
desirable to change it to something which is documented and
user-understood (like the @rev syntax above). This still requires a
network round-trip - although, I think it could be a configuration
option to just serve the file at the original query'd URL for GET requests.
Here's an off-topic question - are there any existing content types
which rely on the query information for rendering user agent-side? In
particular, I'm wondering if something like XForms will fill in a form
based on the values on the URL query. I'm just wondering whether we
would need to process the query or include it in the redirect
-David Waite
SLOGEN wrote:
> kfogel@collab.net wrote:
>
>> Sure, people familiar with a repository probably know where it begins
>> and ends in the URL. But we shouldn't depend on familiarity, because
>> it introduces a "you have to contact a knowledgeable human" step where
>> there doesn't need to be one.
>
>
> This is a powerfull argument against my proposal. Maybe there should
> be and a "pro/cons/fix'es database" of approaches before deciding?
> Here's something to start with.
>
> There are some places where the revision information could be
> consistently placed in an URI:
>
> 1. In a query segment ("?rev=1234")
>
> Pro: Probably easy to implement
>
> Pro: No naming confusion between files and revision-info (if "?rev="
> is used, not "@")
>
> Con: relative URL's and browsing the repository as a whole with at
> other revisions than HEAD (wayback-mode) doesn't work
> Fix: Only use an external (to apache-module) presenter to browse
> repository. This is a rather complex task, if links in files with
> mime-type text/html are to work (viewCVS?)
>
> Con: Users opening directories by URL at a revision will, by
> default, get a list of files which are present in the revision asked,
> but the links in the HTML presented points to files in HEAD (if they
> exist)
> Fix: Make mod_apache present directory-lists differently
>
> Con: attaches revisions to files/path's, instead of repositories
>
> 2. After the repository name (".../repos@1234/...")
>
> Pro: Reflects the "subversion philosophy", that repositories have
> revisions, not files/paths.
>
> Pro: Directly allows browsing in wayback-mode
>
> Con: svn-clients doesn't know where to stick the revision
> Fix: store information about the repository name in the .svn files,
> make it available in API "char * repos_of(const char *file_name);" [1]
>
> Con: users don't know where to stick the revision
> Fix: Interact with user. Possibly time/man-power expensive, but the
> user _is_ trying to get a specific version of the repository, not a
> specific version of one file.
>
> 3. At the beginning of the path ("http://svn.foo/@1234/...)
>
> Pro: Solves Con's from 2.
>
> Con: apache-handlers that match URL's are much harder to write.
> Fix: smarter apache handler setup (is this possible for the
> multi-repository config of apache-module?)
>
> Con: URI information wierdly grouped
> (http://slog.dk/@1234/~jensen/svn/repos)
> Fix: Stop caring.... [2]
>
> 4. Other places?
>
>
> [1] With other types, obviously... simplified for readability in the mail
> [2] Not recommended :)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by SLOGEN <je...@slog.dk>.
kfogel@collab.net wrote:
> Sure, people familiar with a repository probably know where it begins
> and ends in the URL. But we shouldn't depend on familiarity, because
> it introduces a "you have to contact a knowledgeable human" step where
> there doesn't need to be one.
This is a powerfull argument against my proposal. Maybe there should be
and a "pro/cons/fix'es database" of approaches before deciding? Here's
something to start with.
There are some places where the revision information could be
consistently placed in an URI:
1. In a query segment ("?rev=1234")
Pro: Probably easy to implement
Pro: No naming confusion between files and revision-info (if "?rev="
is used, not "@")
Con: relative URL's and browsing the repository as a whole with at
other revisions than HEAD (wayback-mode) doesn't work
Fix: Only use an external (to apache-module) presenter to browse
repository. This is a rather complex task, if links in files with
mime-type text/html are to work (viewCVS?)
Con: Users opening directories by URL at a revision will, by default,
get a list of files which are present in the revision asked, but the
links in the HTML presented points to files in HEAD (if they exist)
Fix: Make mod_apache present directory-lists differently
Con: attaches revisions to files/path's, instead of repositories
2. After the repository name (".../repos@1234/...")
Pro: Reflects the "subversion philosophy", that repositories have
revisions, not files/paths.
Pro: Directly allows browsing in wayback-mode
Con: svn-clients doesn't know where to stick the revision
Fix: store information about the repository name in the .svn files,
make it available in API "char * repos_of(const char *file_name);" [1]
Con: users don't know where to stick the revision
Fix: Interact with user. Possibly time/man-power expensive, but the
user _is_ trying to get a specific version of the repository, not a
specific version of one file.
3. At the beginning of the path ("http://svn.foo/@1234/...)
Pro: Solves Con's from 2.
Con: apache-handlers that match URL's are much harder to write.
Fix: smarter apache handler setup (is this possible for the
multi-repository config of apache-module?)
Con: URI information wierdly grouped
(http://slog.dk/@1234/~jensen/svn/repos)
Fix: Stop caring.... [2]
4. Other places?
[1] With other types, obviously... simplified for readability in the mail
[2] Not recommended :)
--
Helge
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by kf...@collab.net.
Jack Repenning <jr...@collab.net> writes:
> I think the requirement to find the repo point in a URL automatically
> is real, but it's a requirement for "tools like viewcvs or
> TortoiseSVN," Users work with the same repos every day; their primary
> means of parsing the URL is "hey, Joe, which part of this is the
> repository????" And this works just fine in the case at hand ;-)
Not in the free-for-all universe, where you're accessing some
anonymous open source repository that you've never seen before.
Sure, people familiar with a repository probably know where it begins
and ends in the URL. But we shouldn't depend on familiarity, because
it introduces a "you have to contact a knowledgeable human" step where
there doesn't need to be one.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Jack Repenning <jr...@collab.net>.
At 11:17 AM -0700 8/5/03, Robert Spier wrote:
>I was just using RapidSVN as an example of living in a repository
>where the base of the repository URL is definitely non-deterministic.
Ah, I see.
"Hey, Robert, where's the repo in this URL?" ;-)
http://svn.collab.net/repos/svn/clients/rapidsvn/trunk
Ah, "svn ls" tells me it's http://svn.collab.net/repos/svn. So I have
two ways to figure this out. As a developer, I'm happy. Now, let's
fix it for "those tools."
--
-==-
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: Official revision syntax for Subversion URLs
Posted by Robert Spier <rs...@pobox.com>.
At Tue, 5 Aug 2003 11:15:20 -0700,
Jack Repenning wrote:
>
> At 10:49 AM -0700 8/5/03, Robert Spier wrote:
> >Pretend you're a RapidSVN developer,
>
> Does that mean "a developer of RapidSVN"? If so, then I think
> RapidSVN is one of "those tools" with a need to do this. In my last
> message I only pointed out that mere humans, working against their
> familiar repositories, have extra-syntactical ways to do so (which, I
> think, would include "a developer who uses RapidSVN," if that's what
> you meant).
I think I chose a bad example.
I was just using RapidSVN as an example of living in a repository
where the base of the repository URL is definitely non-deterministic.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Jack Repenning <jr...@collab.net>.
At 10:49 AM -0700 8/5/03, Robert Spier wrote:
>Pretend you're a RapidSVN developer,
Does that mean "a developer of RapidSVN"? If so, then I think
RapidSVN is one of "those tools" with a need to do this. In my last
message I only pointed out that mere humans, working against their
familiar repositories, have extra-syntactical ways to do so (which, I
think, would include "a developer who uses RapidSVN," if that's what
you meant).
Now, how can "one of those tools" achieve the goal? I can think of three ways:
- Search for it. Keep prune the path and contact the server to see
if he still thinks this is a resource (the API equivalent of "svn
stat" ought to do the job).
- Modify SVN to record this in .svn/* (probably "entries", say by
adding a token "repo=someHeadOfUrl").
- Extend SVN to provide an API call to return this (given a URL,
return some head of that URL). The library would be free to
implement it in either of the above ways, or any other clever thing
someone might come up with.
--
-==-
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: Official revision syntax for Subversion URLs
Posted by Robert Spier <rs...@pobox.com>.
> I think the requirement to find the repo point in a URL automatically
> is real, but it's a requirement for "tools like viewcvs or
> TortoiseSVN," Users work with the same repos every day; their
> primary means of parsing the URL is "hey, Joe, which part of this is
> the repository????" And this works just fine in the case at hand ;-)
I don't think that's necessarily true.
Pretend you're a RapidSVN developer, and take this URL
http://svn.collab.net/repos/svn/clients/rapidsvn/
For all you know (and potentially all you care), that might be the
base of the repository.
-R
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Jack Repenning <jr...@collab.net>.
At 1:19 PM -0400 8/5/03, John Peacock wrote:
>
>Point taken. But, how often are users going to be expected to go
>spelunking through old revisions without the crutch of a tool like
>viewcvs or TortoiseSVN? Aren't tools with "direct" access to the
>repository able to pull out the root path? If not, then I can see
>the dilemma.
More subtly: how often do users (humans, scripts) do this sort of
thing _on_repos_they_don't_know?
I think the requirement to find the repo point in a URL automatically
is real, but it's a requirement for "tools like viewcvs or
TortoiseSVN," Users work with the same repos every day; their
primary means of parsing the URL is "hey, Joe, which part of this is
the repository????" And this works just fine in the case at hand ;-)
--
-==-
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: Official revision syntax for Subversion URLs
Posted by John Peacock <jp...@rowman.com>.
kfogel@collab.net wrote:
> The problem with this is that the user may not actually know where the
> repository portion of the URL ends and the path portion begins.
> Sometimes it's obvious, sometimes it's not. But there's no algorithm
> for finding it, so programs would have a hard time with this method.
>
> Whereas anyone can find the end of a URL :-).
With both eyes closed... ;~!
Point taken. But, how often are users going to be expected to go spelunking
through old revisions without the crutch of a tool like viewcvs or TortoiseSVN?
Aren't tools with "direct" access to the repository able to pull out the root
path? If not, then I can see the dilemma.
If the syntax is awkward for users without knowledge of the underlying repos
structure, how much of a handicap is that if the more common tools can hide
that? Perhaps just having something that makes sense to implement (which the
tools can easily handle) is more important than having it dead simple for
endusers to cobble together manually?
Is there no URI for WebDAV to access non-HEAD revisions? Could the default
WebDAV HTTP interface be enhanced to provide a secondary link to the change
history for a given file in the repository?
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by kf...@collab.net.
John Peacock <jp...@rowman.com> writes:
> Except that with subversion, you have already specified the branch
> itself, before you specify the path/filename you are interested in.
> Personally, I have to agree with the earlier suggestion to tying the
> revision request to the repository:
>
> http://svn.host/path/to/repository@16254/path/to/file
>
> which has the added advantage that the character '@' only has to be
> forbidden from the repository path name itself (instead of random
> files/directories within the repository).
The problem with this is that the user may not actually know where the
repository portion of the URL ends and the path portion begins.
Sometimes it's obvious, sometimes it's not. But there's no algorithm
for finding it, so programs would have a hard time with this method.
Whereas anyone can find the end of a URL :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by John Peacock <jp...@rowman.com>.
Robert Spier wrote:
>
> To get to the fifteenth version of that file (on the main branch)
> you'd refer to:
> foo@@bar@@baz@@/main/15
>
Except that with subversion, you have already specified the branch itself,
before you specify the path/filename you are interested in. Personally, I have
to agree with the earlier suggestion to tying the revision request to the
repository:
http://svn.host/path/to/repository@16254/path/to/file
which has the added advantage that the character '@' only has to be forbidden
from the repository path name itself (instead of random files/directories within
the repository).
My 2 cents
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Robert Spier <rs...@pobox.com>.
> > What about @@ ?
> > It's what ClearCase uses... and is probably a lot less likely than
> > single '@' to exist.
> Sounds good to me. A question first, though. Does this mean that you
> cannot version path containing '@@' in their names under ClearCase?
> If so -- that is, if ClearCase users are already living with this
> restriction, +1 on us adopting the same system. Otherwise, I'm +0 on
> it.
Turns out, I'm slightly wrong.
The ClearCase separator is actually '@@/'
(but I've always thought of the / as being part of the revision
itself, as opposed to being part of the separator.
So in ClearCase you _can_ have a file named foo@@bar@@baz, if you so
desire,
To get to the fifteenth version of that file (on the main branch)
you'd refer to:
foo@@bar@@baz@@/main/15
-R
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by cm...@collab.net.
Robert Spier <rs...@pobox.com> writes:
> What about @@ ?
>
> It's what ClearCase uses... and is probably a lot less likely than
> single '@' to exist.
>
> On my system, I have many files with @ in them. Many came with the
> operating system (locale files). I have none with @@.
Sounds good to me. A question first, though. Does this mean that you
cannot version path containing '@@' in their names under ClearCase?
If so -- that is, if ClearCase users are already living with this
restriction, +1 on us adopting the same system. Otherwise, I'm +0 on
it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by kf...@collab.net.
Robert Spier <rs...@pobox.com> writes:
> What about @@ ?
>
> It's what ClearCase uses... and is probably a lot less likely than
> single '@' to exist.
>
> On my system, I have many files with @ in them. Many came with the
> operating system (locale files). I have none with @@.
Nice, even better than "@". It's less likely to conflict with
pathnames, it's reasonably intuitive, and it's already familiar to
ClearCase users.
Pretty soon, I'll call for a vote on that syntax, just warning you
all... Just want to see if any other pleasant surprises pop up in this
thread first. :-)
-Karl, of the Imminently Painted Bikeshed
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Robert Spier <rs...@pobox.com>.
At Mon, 04 Aug 2003 23:39:21 +0100,
Philip Martin wrote:
>
> kfogel@collab.net writes:
>
> > However, I have this feeling in the back of my mind that we've always
> > been somewhat tentative about the '@' syntax... Why is that?
>
> The obvious answer is that it makes it more difficult to deal with
> filenames that include '@'. There are quite a few files like that on
> my system, although none of them under Subversion control.
What about @@ ?
It's what ClearCase uses... and is probably a lot less likely than
single '@' to exist.
On my system, I have many files with @ in them. Many came with the
operating system (locale files). I have none with @@.
-R
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Official revision syntax for Subversion URLs
Posted by Philip Martin <ph...@codematters.co.uk>.
kfogel@collab.net writes:
> However, I have this feeling in the back of my mind that we've always
> been somewhat tentative about the '@' syntax... Why is that?
The obvious answer is that it makes it more difficult to deal with
filenames that include '@'. There are quite a few files like that on
my system, although none of them under Subversion control.
I'd prefer something more "obscure", something that has less chance of
of being part of a filename. I suspect that identifying such a
pattern is hard.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Official revision syntax for Subversion URLs
Posted by kf...@collab.net.
[I've changed the name of this thread, so people will know what it's
about.]
Greg Hudson <gh...@MIT.EDU> writes:
> > > and the URL syntax it invents is bogus
> > > (/repos/svn/trunk/README may be a completely different resource
> > > at two different revs).
>
> On Mon, 2003-08-04 at 15:49, kfogel@collab.net wrote:
> > (I'm not sure I understand the problem behind Greg's
> > last objection, but I'm sure he can explain it in more detail).
>
> We've talked about inventing a public URL syntax which includes a
> revision number, and we ruled out using ?rev=revnum. See
> <http://www.contactor.se/~dast/svn/archive-2003-06/0024.shtml>.
Thanks for tracking that down.
Well, we'll need *some* syntax for naming a path at a particular
revision. I'm okay with the "path@rev" syntax the command line client
has been using. It makes the class ".*@[0-9]+$" unavailable for
paths, but a similar objection would apply to any other character.
However, I have this feeling in the back of my mind that we've always
been somewhat tentative about the '@' syntax... Why is that? Am I
imagining things? Are we now ready to proclaim it the Official Way to
specify a revision in a Subversion URL?
Note that currently only the client interprets that syntax. If it's
going to be used by other applications (such as KDE), we'll need to
make the server aware of it as well. I don't see any reason why that
would be hard, but maybe I just haven't thought it through enough? :-)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: KDE's Subversion support are getting better :-)
Posted by Greg Hudson <gh...@MIT.EDU>.
I wrote:
> > and the URL syntax it invents is bogus
> > (/repos/svn/trunk/README may be a completely different resource
> > at two different revs).
On Mon, 2003-08-04 at 15:49, kfogel@collab.net wrote:
> (I'm not sure I understand the problem behind Greg's
> last objection, but I'm sure he can explain it in more detail).
We've talked about inventing a public URL syntax which includes a
revision number, and we ruled out using ?rev=revnum. See
<http://www.contactor.se/~dast/svn/archive-2003-06/0024.shtml>.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: KDE's Subversion support are getting better :-)
Posted by kf...@collab.net.
Jostein Christoffer Andersen <jo...@josander.net> writes:
> On Monday 04 August 2003 18.01, kfogel@collab.net wrote:
> > Neither the web page nor change give Mickael Marchand's email address;
> > do you know it?
>
> Email (from kdevelop's ChangeLog): marchand@kde.org
Thanks, Jostein -- and hello, Mickael. We saw your announcement of
SVN support here:
http://members.shaw.ca/dkite/july252003.html
Thanks for adding it! We're concerned about the URL syntax, though.
You wrote that
svn://svn.collab.net/repos/svn/trunk/README?rev=500 to get revision
500 of the file README :)
This is a problem because "svn://" already has a specific meaning in
Subversion -- it means the ra_svn access layer, as opposed to the
ra_dav access layer, which uses "http://". I'll just quote from Greg
Hudson <gh...@MIT.EDU>'s reaction:
> Oof. That seems bad on several fronts; it maps svn:// URLs to
> HTTP rather than ra_svn, it invents a URL syntax we don't
> support, and the URL syntax it invents is bogus
> (/repos/svn/trunk/README may be a completely different resource
> at two different revs).
We think it's important to avoid each application developing different
syntaxes for accessing versioned resources in Subversion -- otherwise,
what is the "U" in "URI"? :-)
The command line 'svn' client has been (somewhat tentatively) using
URL@REV to indicate specific revisions, but we're certainly open to
other solutions. (I'm not sure I understand the problem behind Greg's
last objection, but I'm sure he can explain it in more detail).
Anyway, if current syntaxes aren't expressive enough, let's discuss it
and find a solution. But we must avoid incompatible overloads, or
users will get very confused.
Best,
-Karl Fogel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: KDE's Subversion support are getting better :-)
Posted by Jostein Christoffer Andersen <jo...@josander.net>.
On Monday 04 August 2003 18.01, kfogel@collab.net wrote:
> > I don't think that's a problem. I think this is just an example of a
> > thing that can be done.
>
> No, Greg's right, this is bad.
>
> "svn://" already means something in the Subversion universe. It will
> be very confusing if KDE makes it mean something else. If KDE wants
> to offer a feature that current SVN syntaxes can't support, then we
> should solve the problem in a compatible way, not by overloading
> existing meanings incompatibly.
>
> It's really losing if Subversion resources use a different URI syntax
> for each application that accesses them. The whole *point* of URI is
> the "U", right? :-)
Ok, you are right both of you. :-)
>
> Neither the web page nor change give Mickael Marchand's email address;
> do you know it?
Email (from kdevelop's ChangeLog): marchand@kde.org
Many people are waiting for Subversion support in KDE, so Mickael
Marchand should know this ASAP.
I don't know Mickael Marchand at all so it might be a good idea that you
(Karl) contact him?
The kio_svn are still beta so it should be possible change it.
Jostein
--
Jostein Chr. Andersen <jo...@josander.net> http://www.josander.net/
Public PGP Key:
Key: http://www.josander.net/pub_keys/jostein_josander.net.asc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: KDE's Subversion support are getting better :-)
Posted by kf...@collab.net.
Jostein Christoffer Andersen <jo...@josander.net> writes:
> On Sunday 03 August 2003 04.41, Greg Hudson wrote:
> > > svn://svn.collab.net/repos/svn/trunk/README?rev=500 to get revision
> > > 500 of the file README :)
> >
> > Oof. That seems bad on several fronts; it maps svn:// URLs to HTTP
> > rather than ra_svn, it invents a URL syntax we don't support, and the
> > URL syntax it invents is bogus (/repos/svn/trunk/README may be a
> > completely different resource at two different revs).
>
> I don't think that's a problem. I think this is just an example of a
> thing that can be done.
No, Greg's right, this is bad.
"svn://" already means something in the Subversion universe. It will
be very confusing if KDE makes it mean something else. If KDE wants
to offer a feature that current SVN syntaxes can't support, then we
should solve the problem in a compatible way, not by overloading
existing meanings incompatibly.
It's really losing if Subversion resources use a different URI syntax
for each application that accesses them. The whole *point* of URI is
the "U", right? :-)
Neither the web page nor change give Mickael Marchand's email address;
do you know it?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: KDE's Subversion support are getting better :-)
Posted by Jostein Christoffer Andersen <jo...@josander.net>.
On Tuesday 05 August 2003 04.10, Scott Lamb wrote:
> On Sunday, Aug 3, 2003, at 04:03 America/Chicago, Jostein Christoffer
>
> Andersen wrote:
> > A more realistic usage of kio_svn are probably intergrated
> > Subversion support in Konqueror (the KDE file manager), maybe
> > something like the wonderful tortoisesvn program for Windows.
>
> Or Cervisia for KDE. They already have something that integrates into
> their shell and does version control stuff, just not for Subversion.
Cervisia will have first rudimentary support for Subversion in the
upcoming kde-3.2 version. :-)
Jostein
--
Jostein Chr. Andersen <jo...@josander.net> http://www.josander.net/
Public PGP Key:
Key: http://www.josander.net/pub_keys/jostein_josander.net.asc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: KDE's Subversion support are getting better :-)
Posted by Scott Lamb <sl...@slamb.org>.
On Sunday, Aug 3, 2003, at 04:03 America/Chicago, Jostein Christoffer
Andersen wrote:
> A more realistic usage of kio_svn are probably intergrated Subversion
> support in Konqueror (the KDE file manager), maybe something like the
> wonderful tortoisesvn program for Windows.
Or Cervisia for KDE. They already have something that integrates into
their shell and does version control stuff, just not for Subversion.
(And there's no cvs:blah URL in KDE AFAIK, so that's not a necessity.
There probably are some other cool things they could do an ioslave,
though.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: KDE's Subversion support are getting better :-)
Posted by Jostein Christoffer Andersen <jo...@josander.net>.
On Sunday 03 August 2003 04.41, Greg Hudson wrote:
> > svn://svn.collab.net/repos/svn/trunk/README?rev=500 to get revision
> > 500 of the file README :)
>
> Oof. That seems bad on several fronts; it maps svn:// URLs to HTTP
> rather than ra_svn, it invents a URL syntax we don't support, and the
> URL syntax it invents is bogus (/repos/svn/trunk/README may be a
> completely different resource at two different revs).
I don't think that's a problem. I think this is just an example of a
thing that can be done.
A more realistic usage of kio_svn are probably intergrated Subversion
support in Konqueror (the KDE file manager), maybe something like the
wonderful tortoisesvn program for Windows.
Jostein
--
Jostein Chr. Andersen <jo...@josander.net> http://www.josander.net/
Public PGP Key:
Key: http://www.josander.net/pub_keys/jostein_josander.net.asc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: KDE's Subversion support are getting better :-)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2003-08-02 at 14:14, Jostein Christoffer Andersen wrote:
> now you can get a file like this :
>
> svn://svn.collab.net/repos/svn/trunk/README?rev=500 to get revision 500
> of the file README :)
Oof. That seems bad on several fronts; it maps svn:// URLs to HTTP
rather than ra_svn, it invents a URL syntax we don't support, and the
URL syntax it invents is bogus (/repos/svn/trunk/README may be a
completely different resource at two different revs).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org