You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Max Bowsher <ma...@ukf.net> on 2005/01/24 20:18:07 UTC
Final(?) Relative Externals format
Below I propose what might just possibly become the final relative externals
syntax. Comment, discuss, and then let's implement! ;-)
For examples, I will use the external which is present in the cvs2svn
repository,
and rewrite it into each of the proposed relative forms.
Existing absolute external:
http://svn.collab.net/repos/svn/trunk/subversion/tests/clients/cmdline/svntest
Relative form 1: Scheme-relative
//svn.collab.net/repos/svn/trunk/subversion/tests/clients/cmdline/svntest
This form is compliant with RFC 2396.
Relative form 2: Host-relative
/repos/svn/trunk/subversion/tests/clients/cmdline/svntest
This form is compliant with RFC 2396.
Relative form 3: Repository-relative
///../svn/trunk/subversion/tests/clients/cmdline/svntest
The concept of a repository within the URL is fairly unique to Subversion,
and hence no suitable syntax is expressed in RFC 2396. This form takes
advantage of the fact that whilst the RFC explicitly specifies the meaning
of a relative URL beginning with zero, one, or two slashes, it is silent on
the matter of three or more slashes.
Therefore I feel this is a good way to accomodate this very useful form of
relativity into an unused (and unlikely to be used) void in the URI
standard.
Relative form 4: Directory-relative
../../svn/trunk/subversion/tests/clients/cmdline/svntest
This form is compliant with RFC 2396.
It is stretching the example somewhat, since it would break on tagging or
branching cvs2svn, since "tags/foo" and "branches/foo" contain a different
number of components to "trunk", but you should get the idea of what the
syntax means, nonetheless.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Branko Čibej <br...@xbc.nu>.
Max Bowsher wrote:
> André Malo wrote:
>
>> * Max Bowsher wrote:
>>
>>> Hmm. I really don't like the concept of a scheme which actually isn't a
>>> scheme, it's a modification applied to some other implied scheme.
>>>
>>> /// makes more sense to me.
>>
>>
>> I tend to disagree. It represents a specific addressing scheme (of a
>> subversion resource) independent from any physical access. A bit like
>> mailto:.
>>
>> Further I don't consider /// as compliant, because there is no rule
>> in RFC
>> 2396, which defines a triple slash at the beginning -> it could be
>> rejected
>> by a strictly compliant URI parser.
>
>
> Only subversion will ever have the ability to correctly interpret
> these URL-like things, so I don't see the above as a problem.
>
> RFC 2396 never envisaged something filling this role, so I don't see
> any problem with exploiting syntax it left undefined to cater to our
> needs.
>
> I don't view this as suitable for a scheme, because scheme: implies an
> absolute URL, and this is not absolute. (A mailto: is absolute).
Absolute, yes, but in the context of the scheme's meaning. It doesn't
have to be "absolute on the net". Witness Mozilla's use of the chrome:
scheme to access GUI resources -- those URLs are absolute in the sense
that chrome: implies a chroot to the installation's resource database.
In the same way, in-repos: would imply a chroot to the top of the
current repository.
Also witness DAV's use of opaquelocktoken: -- it's only meaningful
within a single server.
I'm not saying that using a scheme is better than the triple-slash
construct, only that this usage is not unheard of.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Max Bowsher <ma...@ukf.net>.
André Malo wrote:
> * Max Bowsher wrote:
>
>> Hmm. I really don't like the concept of a scheme which actually isn't a
>> scheme, it's a modification applied to some other implied scheme.
>>
>> /// makes more sense to me.
>
> I tend to disagree. It represents a specific addressing scheme (of a
> subversion resource) independent from any physical access. A bit like
> mailto:.
>
> Further I don't consider /// as compliant, because there is no rule in RFC
> 2396, which defines a triple slash at the beginning -> it could be
> rejected
> by a strictly compliant URI parser.
Only subversion will ever have the ability to correctly interpret these
URL-like things, so I don't see the above as a problem.
RFC 2396 never envisaged something filling this role, so I don't see any
problem with exploiting syntax it left undefined to cater to our needs.
I don't view this as suitable for a scheme, because scheme: implies an
absolute URL, and this is not absolute. (A mailto: is absolute).
My reasons for favouring /// are that it is a short symbolic construction,
which fits in with the general theme of the other relativity specifiers: (
// / ../ )
Also, there is the possibility of re-using this to repair the extreme
verbosity of our command line interface, as compared with CVS's.
For example:
cvs up -r BRANCH
svn sw ///branches/BRANCH
Hence, I am seeking something small, visually-distinctive, that I can type
in under a second.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by André Malo <nd...@perlig.de>.
* Max Bowsher wrote:
> Hmm. I really don't like the concept of a scheme which actually isn't a
> scheme, it's a modification applied to some other implied scheme.
>
> /// makes more sense to me.
I tend to disagree. It represents a specific addressing scheme (of a
subversion resource) independent from any physical access. A bit like
mailto:.
Further I don't consider /// as compliant, because there is no rule in RFC
2396, which defines a triple slash at the beginning -> it could be rejected
by a strictly compliant URI parser.
nd
--
> Rätselnd, was ein Anthroposoph mit Unterwerfung zu tun hat...
^^^^^^^^^^^^
[...] Dieses Wort gibt so viele Stellen für einen Spelling Flame her, und
Du gönnst einem keine einzige. -- Jean Claude und David Kastrup in dtl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Max Bowsher <ma...@ukf.net>.
André Malo wrote:
> * Max Bowsher wrote:
>
>> Relative form 3: Repository-relative
>> ///../svn/trunk/subversion/tests/clients/cmdline/svntest
>>
>> The concept of a repository within the URL is fairly unique to
>> Subversion, and hence no suitable syntax is expressed in RFC 2396. This
>> form takes advantage of the fact that whilst the RFC explicitly specifies
>> the meaning of a relative URL beginning with zero, one, or two slashes,
>> it is silent on the matter of three or more slashes.
>> Therefore I feel this is a good way to accomodate this very useful form
>> of relativity into an unused (and unlikely to be used) void in the URI
>> standard.
>
> It would be quite easy to make this RFC 2396 compliant -- invent a new
> scheme (in-repos or repos-relative or so, I'm not good in naming :-):
>
> in-repos:svn/trunk/subversion/tests/clients/cmdline/svntest
>
> The other variants look fine.
Hmm. I really don't like the concept of a scheme which actually isn't a
scheme, it's a modification applied to some other implied scheme.
/// makes more sense to me.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by André Malo <nd...@perlig.de>.
* Max Bowsher wrote:
> Relative form 3: Repository-relative
> ///../svn/trunk/subversion/tests/clients/cmdline/svntest
>
> The concept of a repository within the URL is fairly unique to
> Subversion, and hence no suitable syntax is expressed in RFC 2396. This
> form takes advantage of the fact that whilst the RFC explicitly specifies
> the meaning of a relative URL beginning with zero, one, or two slashes,
> it is silent on the matter of three or more slashes.
> Therefore I feel this is a good way to accomodate this very useful form
> of relativity into an unused (and unlikely to be used) void in the URI
> standard.
It would be quite easy to make this RFC 2396 compliant -- invent a new
scheme (in-repos or repos-relative or so, I'm not good in naming :-):
in-repos:svn/trunk/subversion/tests/clients/cmdline/svntest
The other variants look fine.
nd
--
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook! Ook? Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook? Ook. Ook! Ook! Ook? Ook! Ook. Ook? Ook. Ook.
Ook. Ook. Ook. Ook. Ook! Ook. Ook! Ook! Ook! Ook! Ook! Ook.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Julian Foad <ju...@btopenworld.com>.
Max Bowsher wrote:
> Julian Foad wrote:
>> Max Bowsher wrote:
>>
>>> Existing absolute external:
>>> http://svn.collab.net/repos/svn/trunk/subversion/tests/clients/cmdline/svntest
>>
>>> Relative form 3: Repository-relative
>>> ///../svn/trunk/subversion/tests/clients/cmdline/svntest
>>
>> (Actually, to make this example realistic, I think "repos/svn" is the path to
>> the repository, so this should be:
>>
>> ///../trunk/subversion/tests/clients/cmdline/svntest
>> )
>
> No, that's not right.
Oops - sorry. I don't know where the cvs2svn repository is, and I completely
mis-read that example. To be clear now, I've found it as a sibling of "svn" at:
http://svn.collab.net/repos/cvs2svn/
> We are in the cvs2svn repository, and go up one level out of it, and
> then into the svn repository.
Oh. I would strongly advise against allowing that usage. That means that your
example relative URL contains part of the path-to-other-repos. Why is that
better than having the whole path-to-other-repos (apart from saving a few
characters)? Yes, it would mean that the site administrator can then move that
group of repositories, say from "/repos/{svn,cvs2svn}" to
"repos/new/{svn,cvs2svn}", but not to "/{svn,cvs2svn}" (unless your ".."
implementation is very bizarre) nor rename them to "/repos/{new-svn,...}".
I see that you were thinking of the repos-relative URL as being a dir-relative
URL whose starting point is the path to the repository root. With a
dir-relative URL you expect to be able to go backwards from its starting point
with "..", but I feel that a repository-relative URL should mean "within the
repository" just as a site-relative one means "within the site" and doesn't
allow you to go relatively from "//tigris.org/" to "/../collab.net/path/".
>> Using the example, what information do we need to know (and hope will remain
>> stable) to make the different kinds of reference?
>>
>> repos-rel: "/trunk/subversion/tests/clients/cmdline/svntest"
>> vs.
>> site-rel: "/repos/svn/" as well.
>>
>> repos-rel: "/trunk/subversion/tests/clients/cmdline/svntest"
>> vs.
>> dir-rel: the in-repo path of where we are now (or at least the depth of
>> it), instead.
>>
>> I believe this indicates that the advantage of adding repository-relative URLs
>> to the other types is slim, because I can't see why the path-to-repo is much
>> more likely to change than the path-within-repo. Am I missing some
>> significant use cases in which the elimination of path-to-repo confers a
>> great advantage?
>
> Dir-rel is utterly useless for this case, since "trunk", and
> "{branches,tags}/foo" have different depth.
Sorry for the confusion. I was using the destination path from your example
without assuming any particular source path, and trying to make general
statements about how the various relative references would work. I agree that
dir-rel is no good for your particular example. The comparison in that case is
between repos-rel and site-rel.
> Building knowledge of the site-to-repository-root path into the
> externals is non-ideal.
Agreed, in the cases where that knowledge is unnecessary, i.e. for references
within a single repository.
> It's just slightly better than the current situation. Since we are
> reworking externals anyway, we should do the best we can do.
>
> I imagine ///tags/FOO/somemodule being a very common kind of external.
> Think of any module which wishes to import known-good versions of other
> modules in the same repository.
Yes. That use case is good. It would be very nice to have a syntax for those
in-repository references. It would be a bit nicer still if the syntax were to
be brief, like the triple-slash idea is, to make it convenient for typing.
>>> form takes advantage of the fact that whilst the RFC explicitly
>>> specifies the meaning of a relative URL beginning with zero, one, or two
>>> slashes, it is silent on the matter of three or more slashes.
>>> Therefore I feel this is a good way to accomodate this very useful form
>>> of relativity into an unused (and unlikely to be used) void in the URI
>>> standard.
>>
>> Bad assumption ("Therefore"). If you think you can so easily assign
>> your own
>> meaning to three slashes, don't you think other people are, even now,
>> assigning their own meanings? Down this path lies a likelihood of
>> conflicts.
>
> But, I was assigning a meaning local to subversion - so who is there to
> conflict with?
Well, who knows? Take the example of SVK and the double-slash URLs, and
imagine he'd chosen triple-slash.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Max Bowsher <ma...@ukf.net>.
Julian Foad wrote:
> Max Bowsher wrote:
>> Existing absolute external:
>> http://svn.collab.net/repos/svn/trunk/subversion/tests/clients/cmdline/svntest
>
>> Relative form 3: Repository-relative
>> ///../svn/trunk/subversion/tests/clients/cmdline/svntest
>
> (Actually, to make this example realistic, I think "repos/svn" is the path
> to
> the repository, so this should be:
>
> ///../trunk/subversion/tests/clients/cmdline/svntest
> )
No, that's not right.
We are in the cvs2svn repository, and go up one level out of it, and then
into the svn repository.
>> The concept of a repository within the URL is fairly unique to
>> Subversion, and hence no suitable syntax is expressed in RFC 2396. This
>
> I agree that repository-relative URLs seem like a good thing to have.
> However, perhaps the need is not quite so strong.
>
> The use of a repository-relative URL is in accessing a sibling project, or
> a
> different tag/branch/trunk of the same project, within the same
> repository.
> Compared with a directory-relative URL, you gain by not having to know how
> many directories to go up (from where you are currently), but you may lose
> by
> needing to know the full in-repository path to the external directory.
> Compared with a site-relative URL, you gain by not having to know the path
> to
> the repository, but often the site administrator will make that path short
> and
> relatively stable anyway.
>
> Using the example, what information do we need to know (and hope will
> remain
> stable) to make the different kinds of reference?
>
> repos-rel: "/trunk/subversion/tests/clients/cmdline/svntest"
> vs.
> site-rel: "/repos/svn/" as well.
>
> repos-rel: "/trunk/subversion/tests/clients/cmdline/svntest"
> vs.
> dir-rel: the in-repo path of where we are now (or at least the depth
> of
> it), instead.
>
> I believe this indicates that the advantage of adding repository-relative
> URLs
> to the other types is slim, because I can't see why the path-to-repo is
> much
> more likely to change than the path-within-repo. Am I missing some
> significant use cases in which the elimination of path-to-repo confers a
> great advantage?
Dir-rel is utterly useless for this case, since "trunk", and
"{branches,tags}/foo" have different depth.
Building knowledge of the site-to-repository-root path into the externals is
non-ideal.
It's just slightly better than the current situation. Since we are reworking
externals anyway, we should do the best we can do.
I imagine ///tags/FOO/somemodule being a very common kind of external.
Think of any module which wishes to import known-good versions of other
modules in the same repository.
>> form takes advantage of the fact that whilst the RFC explicitly
>> specifies the meaning of a relative URL beginning with zero, one, or two
>> slashes, it is silent on the matter of three or more slashes.
>> Therefore I feel this is a good way to accomodate this very useful form
>> of relativity into an unused (and unlikely to be used) void in the URI
>> standard.
>
> Bad assumption ("Therefore"). If you think you can so easily assign your
> own
> meaning to three slashes, don't you think other people are, even now,
> assigning their own meanings? Down this path lies a likelihood of
> conflicts.
But, I was assigning a meaning local to subversion - so who is there to
conflict with?
> Apart from that, it looks good. How about proceeding with the other types
> of
> relative URL, and leaving repository-relative out until a pressing need
> for it
> is demonstrated?
Demonstrated above.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Julian Foad <ju...@btopenworld.com>.
Max Bowsher wrote:
> Existing absolute external:
> http://svn.collab.net/repos/svn/trunk/subversion/tests/clients/cmdline/svntest
> Relative form 3: Repository-relative
> ///../svn/trunk/subversion/tests/clients/cmdline/svntest
(Actually, to make this example realistic, I think "repos/svn" is the path to
the repository, so this should be:
///../trunk/subversion/tests/clients/cmdline/svntest
)
> The concept of a repository within the URL is fairly unique to
> Subversion, and hence no suitable syntax is expressed in RFC 2396. This
I agree that repository-relative URLs seem like a good thing to have. However,
perhaps the need is not quite so strong.
The use of a repository-relative URL is in accessing a sibling project, or a
different tag/branch/trunk of the same project, within the same repository.
Compared with a directory-relative URL, you gain by not having to know how many
directories to go up (from where you are currently), but you may lose by
needing to know the full in-repository path to the external directory.
Compared with a site-relative URL, you gain by not having to know the path to
the repository, but often the site administrator will make that path short and
relatively stable anyway.
Using the example, what information do we need to know (and hope will remain
stable) to make the different kinds of reference?
repos-rel: "/trunk/subversion/tests/clients/cmdline/svntest"
vs.
site-rel: "/repos/svn/" as well.
repos-rel: "/trunk/subversion/tests/clients/cmdline/svntest"
vs.
dir-rel: the in-repo path of where we are now (or at least the depth of
it), instead.
I believe this indicates that the advantage of adding repository-relative URLs
to the other types is slim, because I can't see why the path-to-repo is much
more likely to change than the path-within-repo. Am I missing some significant
use cases in which the elimination of path-to-repo confers a great advantage?
> form takes advantage of the fact that whilst the RFC explicitly
> specifies the meaning of a relative URL beginning with zero, one, or two
> slashes, it is silent on the matter of three or more slashes.
> Therefore I feel this is a good way to accomodate this very useful form
> of relativity into an unused (and unlikely to be used) void in the URI
> standard.
Bad assumption ("Therefore"). If you think you can so easily assign your own
meaning to three slashes, don't you think other people are, even now, assigning
their own meanings? Down this path lies a likelihood of conflicts.
Apart from that, it looks good. How about proceeding with the other types of
relative URL, and leaving repository-relative out until a pressing need for it
is demonstrated?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2005-01-24 at 15:33, Max Bowsher wrote:
> I'm mainly including it to cover the possibility of multiple related servers
> which can be accessed both by http: or https:.
> Since RFC 2396 assigns a specific meaning to this format, we wouldn't want
> to use it for something non-standard, so we aren't losing anything by
> implementing it.
I wouldn't get too hung up on the relative-URL standard if it doesn't
meet our needs. We already have a syntax in the command-line client for
URL-or-path which doesn't follow the relative-URL standard; I would be
more concerned with consistency with that syntax (where it makes sense,
e.g. if we add a syntax for repository-relative paths to the client)
than with a web standard which doesn't really do what we want.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Max Bowsher <ma...@ukf.net>.
Branko Čibej wrote:
> Max Bowsher wrote:
>
>> Below I propose what might just possibly become the final relative
>> externals syntax. Comment, discuss, and then let's implement! ;-)
>>
>>
>> For examples, I will use the external which is present in the cvs2svn
>> repository,
>> and rewrite it into each of the proposed relative forms.
>>
>> Existing absolute external:
>> http://svn.collab.net/repos/svn/trunk/subversion/tests/clients/cmdline/svntest
>>
>>
>>
>> Relative form 1: Scheme-relative
>> //svn.collab.net/repos/svn/trunk/subversion/tests/clients/cmdline/svntest
>
> How useful is this form in practice? It allows you do redirect to
> another server without specifying the scheme, but there's no guarantee
> that the client will be able to access the other server using hte same
> access method.
>
> Or do you expect the client to ask for the scheme at checkout time?
I'm mainly including it to cover the possibility of multiple related servers
which can be accessed both by http: or https:.
Since RFC 2396 assigns a specific meaning to this format, we wouldn't want
to use it for something non-standard, so we aren't losing anything by
implementing it.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by André Malo <nd...@perlig.de>.
* Julian Foad wrote:
> André Malo wrote:
> > * Branko Čibej wrote:
> >>>Relative form 1: Scheme-relative
> >>
> >>//svn.collab.net/repos/svn/trunk/subversion/tests/clients/cmdline/svnte
> >>st
> >>
> >>How useful is this form in practice? It allows you do redirect to
> >>another server without specifying the scheme, but there's no guarantee
> >>that the client will be able to access the other server using hte same
> >>access method.
> >
> > Consider multiple repositories on the same server, all accessable via
> > http (say, readonly) and https (read+write). That could be a use case,
> > I'd guess.
>
> That doesn't sound like a use case to me: there's no reason to include
> the server host name in that case.
Except if you use different hostnames for https (separate IP) and http.
Gets somehow esotheric now ;)
nd
--
>>> Muschelflucht-Zusatzeinrichtung.
>> Shell-Escape ist ja noch klar, aber `Zusatzeinrichtung'?
> extension?
Feature. -- gefunden in de.org.ccc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Julian Foad <ju...@btopenworld.com>.
André Malo wrote:
> * Branko Čibej wrote:
>>>Relative form 1: Scheme-relative
>>
>>//svn.collab.net/repos/svn/trunk/subversion/tests/clients/cmdline/svntest
>>
>>How useful is this form in practice? It allows you do redirect to
>>another server without specifying the scheme, but there's no guarantee
>>that the client will be able to access the other server using hte same
>>access method.
>
> Consider multiple repositories on the same server, all accessable via http
> (say, readonly) and https (read+write). That could be a use case, I'd
> guess.
That doesn't sound like a use case to me: there's no reason to include the
server host name in that case.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by André Malo <nd...@perlig.de>.
* Branko Čibej wrote:
> > Relative form 1: Scheme-relative
>
> //svn.collab.net/repos/svn/trunk/subversion/tests/clients/cmdline/svntest
>
> How useful is this form in practice? It allows you do redirect to
> another server without specifying the scheme, but there's no guarantee
> that the client will be able to access the other server using hte same
> access method.
Consider multiple repositories on the same server, all accessable via http
(say, readonly) and https (read+write). That could be a use case, I'd
guess.
nd
--
package Hacker::Perl::Another::Just;print
qq~@{[reverse split/::/ =>__PACKAGE__]}~;
# André Malo # http://pub.perlig.de #
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Branko Čibej <br...@xbc.nu>.
Max Bowsher wrote:
> Below I propose what might just possibly become the final relative
> externals syntax. Comment, discuss, and then let's implement! ;-)
>
>
> For examples, I will use the external which is present in the cvs2svn
> repository,
> and rewrite it into each of the proposed relative forms.
>
> Existing absolute external:
> http://svn.collab.net/repos/svn/trunk/subversion/tests/clients/cmdline/svntest
>
>
>
> Relative form 1: Scheme-relative
> //svn.collab.net/repos/svn/trunk/subversion/tests/clients/cmdline/svntest
How useful is this form in practice? It allows you do redirect to
another server without specifying the scheme, but there's no guarantee
that the client will be able to access the other server using hte same
access method.
Or do you expect the client to ask for the scheme at checkout time?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Max Bowsher <ma...@ukf.net>.
John Peacock wrote:
> Max Bowsher wrote:
>> svn_ra_get_repos_root should work just fine. Though solving 960 would
>> also be nice.
>
> No, I understand that the data is _available_ at the RA layer, but it
> isn't
> stored anywhere in the WC files. So, either 960 has to be implemented
> (probably by rewriting a certain percentage of the WC code) or some other
> command line option has to be added (perhaps as an option to `svn info`)
> to
> query the repository and return the repos-root. From the command-line
> user's
> standpoint, the repos-root is currently a hidden value.
Sure, fixing #960 would be *nice*. But it doesn't block the implementation
of repos-relative externals. Just makes them a tiny bit harder to set up.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by John Peacock <jp...@rowman.com>.
Max Bowsher wrote:
> svn_ra_get_repos_root should work just fine. Though solving 960 would
> also be nice.
No, I understand that the data is _available_ at the RA layer, but it isn't
stored anywhere in the WC files. So, either 960 has to be implemented (probably
by rewriting a certain percentage of the WC code) or some other command line
option has to be added (perhaps as an option to `svn info`) to query the
repository and return the repos-root. From the command-line user's standpoint,
the repos-root is currently a hidden value.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Max Bowsher <ma...@ukf.net>.
John Peacock wrote:
> Julian Foad wrote:
>> Max Bowsher wrote:
>>
>>> I still feel strongly that we need a repos-root-relative externals
>>> capability.
>>>
>>> It's a rather horrible design to require hardcoding the served path of
>>> a repository into the repository, when there is no real reason to do so.
>>
>>
>> +1. Well said. If you accept that it must mean "within this
>> repository" and not allow navigating out of the repository with "..",
>> then I think the case has been made for including that facility. Now we
>> only (!) need to agree on a syntax.
>
> Not to throw water on the nice fire you are building, but this brings up a
> question:
> The client code currenty does not (at the WC level at least) know what
> portion
> of the URL is the repository root directory and what part is the
> root-relative
> path that you need to know in order to create the externals.
>
> Since this is the case, are we going to be automatically limiting the
> usage of
> such externals to people who know how the repository itself is structured?
> Wouldn't it be better to somehow expose the information (see issue #960)
> so
> that the user would have a way to discern this information?
svn_ra_get_repos_root should work just fine. Though solving 960 would also
be nice.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by John Peacock <jp...@rowman.com>.
Julian Foad wrote:
> Max Bowsher wrote:
>
>> I still feel strongly that we need a repos-root-relative externals
>> capability.
>>
>> It's a rather horrible design to require hardcoding the served path of
>> a repository into the repository, when there is no real reason to do so.
>
>
> +1. Well said. If you accept that it must mean "within this
> repository" and not allow navigating out of the repository with "..",
> then I think the case has been made for including that facility. Now we
> only (!) need to agree on a syntax.
Not to throw water on the nice fire you are building, but this brings up a question:
The client code currenty does not (at the WC level at least) know what portion
of the URL is the repository root directory and what part is the root-relative
path that you need to know in order to create the externals.
Since this is the case, are we going to be automatically limiting the usage of
such externals to people who know how the repository itself is structured?
Wouldn't it be better to somehow expose the information (see issue #960) so that
the user would have a way to discern this information?
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Julian Foad <ju...@btopenworld.com>.
Max Bowsher wrote:
> I still feel strongly that we need a repos-root-relative externals
> capability.
>
> It's a rather horrible design to require hardcoding the served path of a
> repository into the repository, when there is no real reason to do so.
+1. Well said. If you accept that it must mean "within this repository" and
not allow navigating out of the repository with "..", then I think the case has
been made for including that facility. Now we only (!) need to agree on a syntax.
I can now see repos-root-relative externals as being one of the primary types,
along with absolute and dir-relative. Then comes site-relative, and finally,
in my mind, scheme-relative.
I don't think I've seen a convincing argument for supporting scheme-relative
references. (I can't think of a good scenario in which people want their
access method for an externally hosted repository to track the access method
for their main repository.) Because the syntax for them conflicts with SVK and
also may be confused with UNC path syntax, I feel it is probably best not to
support them, despite initially saying otherwise.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Max Bowsher <ma...@ukf.net>.
Shurik O wrote:
>>> How about a repository that is accessed using svn:// (svnserve -r) or
>>> http:// from the inside and
>>> svn+ssh:// from the outside? ...
>
>> True, but this kind of setup is explicitly recommended against in
>> Subversion's documentation. We recommend that people pick an RA method
>> and stick with it.
We do?
I'm running all my non-trivial repositories over both access methods
simultaneously, because svn: is faster but http: is conveniently linkable.
> I see. I might have missed this recommendation because it is inside a
> section named "Supporting Multiple Repository Access Methods" and explains
> in
> great detail how to do just that :-)
>
> Seriously though, I am concerned that once decided, I will have to stick
> with
> this method forever. Otherwise, if I change the repository access URL two
> years
> from now I will lose the access to today's versions of the code.
>
> Hardly a good option. In this sense host-relative paths are just as bad as
> the absolute ones.
Indeed.
I still feel strongly that we need a repos-root-relative externals
capability.
It's a rather horrible design to require hardcoding the served path of a
repository into the repository, when there is no real reason to do so.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Shurik O <sh...@gmail.com>.
>> How about a repository that is accessed using svn:// (svnserve -r) or
>> http:// from the inside and
>> svn+ssh:// from the outside? ...
> True, but this kind of setup is explicitly recommended against in
> Subversion's documentation. We recommend that people pick an RA method
> and stick with it.
I see. I might have missed this recommendation because it is inside a
section named "Supporting Multiple Repository Access Methods" and explains in great
detail how to do just that :-)
Seriously though, I am concerned that once decided, I will have to stick with this
method forever. Otherwise, if I change the repository access URL two years from now I will
lose the access to today's versions of the code.
Hardly a good option. In this sense host-relative paths are just as bad as the absolute ones.
Brian W. Fitzpatrick wrote on 01/25/2005 2:07 PM:
>
> On Jan 25, 2005, at 12:48 PM, Shurik O wrote:
>
>>>> I just don't see the point in introducing this in addition to
>>>> host-relative paths--how often does a repository move on a server?
>>>> I mean really? I just don't think that the overhead of yet another
>>>> relative form is a lesser evil than having to just deal with
>>>> externals in a moved repository every 30 years when you move a
>>>> repository on a server. Still -0.9 on this.
>>
>>
>> How about a repository that is accessed using svn:// (svnserve -r) or
>> http:// from the inside and
>> svn+ssh:// from the outside?
>>
>> The latter's repository path is very likely to be different from that
>> of the former.
>
>
> True, but this kind of setup is explicitly recommended against in
> Subversion's documentation. We recommend that people pick an RA method
> and stick with it.
>
> -Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2005-01-25 at 17:07, Brian W. Fitzpatrick wrote:
> True, but this kind of setup is explicitly recommended against in
> Subversion's documentation. We recommend that people pick an RA method
> and stick with it.
I think we make that recommendation because you're much more likely to
have BDB permissions problems if you don't stick with one RA method.
With an FSFS repository, there's very little reason to make that
recommendation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Jan 25, 2005, at 12:48 PM, Shurik O wrote:
>>> I just don't see the point in introducing this in addition to
>>> host-relative paths--how often does a repository move on a server?
>>> I mean really? I just don't think that the overhead of yet another
>>> relative form is a lesser evil than having to just deal with
>>> externals in a moved repository every 30 years when you move a
>>> repository on a server. Still -0.9 on this.
>
> How about a repository that is accessed using svn:// (svnserve -r) or
> http:// from the inside and
> svn+ssh:// from the outside?
>
> The latter's repository path is very likely to be different from that
> of the former.
True, but this kind of setup is explicitly recommended against in
Subversion's documentation. We recommend that people pick an RA method
and stick with it.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Shurik O <sh...@gmail.com>.
>> I just don't see the point in introducing this in addition to
>> host-relative paths--how often does a repository move on a server? I
>> mean really? I just don't think that the overhead of yet another
>> relative form is a lesser evil than having to just deal with externals
>> in a moved repository every 30 years when you move a repository on a
>> server. Still -0.9 on this.
How about a repository that is accessed using svn:// (svnserve -r) or http:// from the inside and
svn+ssh:// from the outside?
The latter's repository path is very likely to be different from that of the former.
Brian W. Fitzpatrick wrote on 01/25/2005 9:36 AM:
>
> On Jan 24, 2005, at 4:58 PM, Max Bowsher wrote:
>
>> Brian W. Fitzpatrick wrote:
>>
>>> On Jan 24, 2005, at 12:18 PM, Max Bowsher wrote:
>>>
>>>> Relative form 3: Repository-relative
>>>> ///../svn/trunk/subversion/tests/clients/cmdline/svntest
>>>>
>>>> The concept of a repository within the URL is fairly unique to
>>>> Subversion, and hence no suitable syntax is expressed in RFC 2396.
>>>> This form takes advantage of the fact that whilst the RFC explicitly
>>>> specifies the meaning of a relative URL beginning with zero, one, or
>>>> two slashes, it is silent on the matter of three or more slashes.
>>>> Therefore I feel this is a good way to accomodate this very useful
>>>> form of relativity into an unused (and unlikely to be used) void in
>>>> the URI standard.
>>>
>>>
>>> Ew. Given form 2, I think that this is unnecessary. -0.9
>>
>>
>> Things doable with this form are also doable with form 2, but it
>> involves hardcoding the path-to-repository on the server into the
>> external. I.e., this doesn't fully solve the "repositories may move"
>> problem, just makes it a little less severe.
>
>
>> IMO, we really are overdue for some "repository root relative"
>> notation for use both on the command line, so it seems reasonable to
>> do it for externals too.
>>
>> Please clarify "Ew.".
>
>
> I just don't see the point in introducing this in addition to
> host-relative paths--how often does a repository move on a server? I
> mean really? I just don't think that the overhead of yet another
> relative form is a lesser evil than having to just deal with externals
> in a moved repository every 30 years when you move a repository on a
> server. Still -0.9 on this.
>
>>>> Relative form 4: Directory-relative
>>>> ../../svn/trunk/subversion/tests/clients/cmdline/svntest
>>>>
>>>> This form is compliant with RFC 2396.
>>>> It is stretching the example somewhat, since it would break on tagging
>>>> or branching cvs2svn, since "tags/foo" and "branches/foo" contain a
>>>> different number of components to "trunk", but you should get the idea
>>>> of what the syntax means, nonetheless.
>>>
>>>
>>> Seeing how fragile this is, esp. WRT tagging and branching, I'm also
>>> -0.9 on this.
>>
>>
>> No, this is often requested. Without it, it's impossible to make links
>> within the scope of a single {trunk,tags,braches} set, and have them
>> work properly with branching and tagging.
>
>
> OK. I think I understand this schema better now and I'm fine with it.
>
> I know I'm being a bit of a bastard here, but I just want us to think
> long and hard about each different relative scheme that we add as the
> more we add, the more confusion it's going to create for our
> (non-superhuman) users.
>
> -Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Michael Sweet <mi...@easysw.com>.
Greg Hudson wrote:
> On Tue, 2005-01-25 at 14:02, Max Bowsher wrote:
>
>>Good, I think general consensus is that all 3 forms drawn from RFC2396 are
>>acceptable - so we can split the controversial repository relative
>>discussion off into a seperate discussion.
>
>
> Big party pooper here:
>
> I think the forms drawn from RFC2396 are terribly user-unfriendly, and
> rely on people memorizing a map from obscure leading punctuation to
> semantics.
FWIW, a replacement for RFC 2396 was just published: RFC 3986. I
haven't done an exhaustive comparison, however it does address the
"../" type of relative reference, so all of the following are valid
relative references:
//host/path (relative to current scheme)
///path (relative to current scheme and host)
/path (absolute filename or same as ///path)
path (relative URI to current)
../path (relative URI to current)
The scheme can be placed in front of any relative reference to
make it a URI (so strictly speaking a relative reference is not
a URI).
> Relative URLs in the context of the web are fairly user-friendly because
> there is no distinction between "the site" and "the repository". So a
> link to "/path" is pretty clearly site-relative. We don't have that
> luxury.
>
> So I'm -0.5 on the RFC2396 forms. I recommend making everything very
> explicit, using keywords like "site", "repos", and "scheme" at at the
> beginning of the externals (possibly in all-caps in hopes of
> distinguishing the keywords from user path elements, although of course
> user path elements can be in all-caps as well).
In the case of the svn:externals property, I think the URI context
is clear, so we can allow any of the relative reference forms above.
However, when specifying a URI on the command-line, I agree that
the context is not clear and we should require a scheme.
I know I don't have a vote, but "repos" would seem to be unambiguous,
giving us the following acceptable forms:
file:/path (absolute)
file:///path (absolute)
http://host/path (absolute)
https://host/path (absolute)
repos://host/path (relative to current scheme)
repos:///path (relative to current scheme and host)
repos:path (relative URI to current)
repos:../path (relative URI to current)
svn://host/path (absolute)
svn+ssh://host/path (absolute)
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Julian Foad <ju...@btopenworld.com>.
Julian Foad wrote:
> We could say, the "external" property contains one of: [...]
Sorry - that was a hasty, unconsidered response. (A "drive-by" idea, do you
call it?)
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Julian Foad <ju...@btopenworld.com>.
Greg Hudson wrote:
> I think the forms drawn from RFC2396 are terribly user-unfriendly, and
> rely on people memorizing a map from obscure leading punctuation to
> semantics.
>
> Relative URLs in the context of the web are fairly user-friendly because
> there is no distinction between "the site" and "the repository". So a
> link to "/path" is pretty clearly site-relative. We don't have that
> luxury.
Good point. Perhaps we shouldn't aim to implement relative "URLs" as such, but
rather relative Subversion repository references - which is semantically rather
different. As far as I know there is no reason why the "external" property
need be thought of as containing always some sort of URL.
We could say, the "external" property contains one of:
+ an absolute URL (usually to within another repository)
+ an absolute or relative path within this repository (not going outside this
repository's root)
Syntax for the latter to be determined. Those forms might be all we need.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Michael Brouwer <mi...@tlaloc.net>.
I agree with Greg on this. I'd like to throw in that whatever scheme
you come up with for using in externals should probably be usable from
the command line client anywhere a URL is expected as well. This would
really improve the UI of svn. This does mean that you can't use
repository relative schemes that look like regular paths since the
client need to be able to distinguish a path to a wc from a (relative)
path to a repository.
Michael
On Jan 26, 2005, at 10:37 AM, Greg Hudson wrote:
> On Tue, 2005-01-25 at 14:02, Max Bowsher wrote:
>> Good, I think general consensus is that all 3 forms drawn from
>> RFC2396 are
>> acceptable - so we can split the controversial repository relative
>> discussion off into a seperate discussion.
>
> Big party pooper here:
>
> I think the forms drawn from RFC2396 are terribly user-unfriendly, and
> rely on people memorizing a map from obscure leading punctuation to
> semantics.
>
> Relative URLs in the context of the web are fairly user-friendly
> because
> there is no distinction between "the site" and "the repository". So a
> link to "/path" is pretty clearly site-relative. We don't have that
> luxury.
>
> So I'm -0.5 on the RFC2396 forms. I recommend making everything very
> explicit, using keywords like "site", "repos", and "scheme" at at the
> beginning of the externals (possibly in all-caps in hopes of
> distinguishing the keywords from user path elements, although of course
> user path elements can be in all-caps as well).
>
>
> ---------------------------------------------------------------------
> 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: Final(?) Relative Externals format
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2005-01-25 at 14:02, Max Bowsher wrote:
> Good, I think general consensus is that all 3 forms drawn from RFC2396 are
> acceptable - so we can split the controversial repository relative
> discussion off into a seperate discussion.
Big party pooper here:
I think the forms drawn from RFC2396 are terribly user-unfriendly, and
rely on people memorizing a map from obscure leading punctuation to
semantics.
Relative URLs in the context of the web are fairly user-friendly because
there is no distinction between "the site" and "the repository". So a
link to "/path" is pretty clearly site-relative. We don't have that
luxury.
So I'm -0.5 on the RFC2396 forms. I recommend making everything very
explicit, using keywords like "site", "repos", and "scheme" at at the
beginning of the externals (possibly in all-caps in hopes of
distinguishing the keywords from user path elements, although of course
user path elements can be in all-caps as well).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Max Bowsher <ma...@ukf.net>.
Brian W. Fitzpatrick wrote:
> On Jan 24, 2005, at 4:58 PM, Max Bowsher wrote:
>
>> Brian W. Fitzpatrick wrote:
>>> On Jan 24, 2005, at 12:18 PM, Max Bowsher wrote:
>>>
>>>> Relative form 3: Repository-relative
>>>> ///../svn/trunk/subversion/tests/clients/cmdline/svntest
>>>>
>>>> The concept of a repository within the URL is fairly unique to
>>>> Subversion, and hence no suitable syntax is expressed in RFC 2396.
>>>> This form takes advantage of the fact that whilst the RFC explicitly
>>>> specifies the meaning of a relative URL beginning with zero, one, or
>>>> two slashes, it is silent on the matter of three or more slashes.
>>>> Therefore I feel this is a good way to accomodate this very useful
>>>> form of relativity into an unused (and unlikely to be used) void in
>>>> the URI standard.
>>>
>>> Ew. Given form 2, I think that this is unnecessary. -0.9
>>
>> Things doable with this form are also doable with form 2, but it
>> involves hardcoding the path-to-repository on the server into the
>> external. I.e., this doesn't fully solve the "repositories may move"
>> problem, just makes it a little less severe.
>
>> IMO, we really are overdue for some "repository root relative"
>> notation for use both on the command line, so it seems reasonable to
>> do it for externals too.
>>
>> Please clarify "Ew.".
>
> I just don't see the point in introducing this in addition to
> host-relative paths--how often does a repository move on a server? I
> mean really? I just don't think that the overhead of yet another
> relative form is a lesser evil than having to just deal with externals
> in a moved repository every 30 years when you move a repository on a
> server. Still -0.9 on this.
...
> I know I'm being a bit of a bastard here, but I just want us to think
> long and hard about each different relative scheme that we add as the
> more we add, the more confusion it's going to create for our
> (non-superhuman) users.
That's OK, I'm not offended - it would be a pretty boring discussion if
no-one ever made a counter-proposal! :-)
I'm still in favour of this, though.
I agree that everything that can be done with repository relative paths, can
be done with host-relative paths, but I view relying on that to avoid having
to design a repository relative path syntax as a bit of a kludge.
I'm a bit busy for the next few days, so I'm going to step back and take a
bit of time to form what I hope will be a cogent argument for including this
feature.
>>>> Relative form 4: Directory-relative
>>>> ../../svn/trunk/subversion/tests/clients/cmdline/svntest
>>>>
>>>> This form is compliant with RFC 2396.
>>>> It is stretching the example somewhat, since it would break on
>>>> tagging
>>>> or branching cvs2svn, since "tags/foo" and "branches/foo" contain a
>>>> different number of components to "trunk", but you should get the
>>>> idea
>>>> of what the syntax means, nonetheless.
>>>
>>> Seeing how fragile this is, esp. WRT tagging and branching, I'm also
>>> -0.9 on this.
>>
>> No, this is often requested. Without it, it's impossible to make links
>> within the scope of a single {trunk,tags,braches} set, and have them
>> work properly with branching and tagging.
>
> OK. I think I understand this schema better now and I'm fine with it.
Good, I think general consensus is that all 3 forms drawn from RFC2396 are
acceptable - so we can split the controversial repository relative
discussion off into a seperate discussion.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Jan 24, 2005, at 4:58 PM, Max Bowsher wrote:
> Brian W. Fitzpatrick wrote:
>> On Jan 24, 2005, at 12:18 PM, Max Bowsher wrote:
>>
>>> Relative form 3: Repository-relative
>>> ///../svn/trunk/subversion/tests/clients/cmdline/svntest
>>>
>>> The concept of a repository within the URL is fairly unique to
>>> Subversion, and hence no suitable syntax is expressed in RFC 2396.
>>> This form takes advantage of the fact that whilst the RFC explicitly
>>> specifies the meaning of a relative URL beginning with zero, one, or
>>> two slashes, it is silent on the matter of three or more slashes.
>>> Therefore I feel this is a good way to accomodate this very useful
>>> form of relativity into an unused (and unlikely to be used) void in
>>> the URI standard.
>>
>> Ew. Given form 2, I think that this is unnecessary. -0.9
>
> Things doable with this form are also doable with form 2, but it
> involves hardcoding the path-to-repository on the server into the
> external. I.e., this doesn't fully solve the "repositories may move"
> problem, just makes it a little less severe.
> IMO, we really are overdue for some "repository root relative"
> notation for use both on the command line, so it seems reasonable to
> do it for externals too.
>
> Please clarify "Ew.".
I just don't see the point in introducing this in addition to
host-relative paths--how often does a repository move on a server? I
mean really? I just don't think that the overhead of yet another
relative form is a lesser evil than having to just deal with externals
in a moved repository every 30 years when you move a repository on a
server. Still -0.9 on this.
>>> Relative form 4: Directory-relative
>>> ../../svn/trunk/subversion/tests/clients/cmdline/svntest
>>>
>>> This form is compliant with RFC 2396.
>>> It is stretching the example somewhat, since it would break on
>>> tagging
>>> or branching cvs2svn, since "tags/foo" and "branches/foo" contain a
>>> different number of components to "trunk", but you should get the
>>> idea
>>> of what the syntax means, nonetheless.
>>
>> Seeing how fragile this is, esp. WRT tagging and branching, I'm also
>> -0.9 on this.
>
> No, this is often requested. Without it, it's impossible to make links
> within the scope of a single {trunk,tags,braches} set, and have them
> work properly with branching and tagging.
OK. I think I understand this schema better now and I'm fine with it.
I know I'm being a bit of a bastard here, but I just want us to think
long and hard about each different relative scheme that we add as the
more we add, the more confusion it's going to create for our
(non-superhuman) users.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Max Bowsher <ma...@ukf.net>.
Brian W. Fitzpatrick wrote:
> On Jan 24, 2005, at 12:18 PM, Max Bowsher wrote:
>
>> Relative form 3: Repository-relative
>> ///../svn/trunk/subversion/tests/clients/cmdline/svntest
>>
>> The concept of a repository within the URL is fairly unique to
>> Subversion, and hence no suitable syntax is expressed in RFC 2396.
>> This form takes advantage of the fact that whilst the RFC explicitly
>> specifies the meaning of a relative URL beginning with zero, one, or
>> two slashes, it is silent on the matter of three or more slashes.
>> Therefore I feel this is a good way to accomodate this very useful
>> form of relativity into an unused (and unlikely to be used) void in
>> the URI standard.
>
> Ew. Given form 2, I think that this is unnecessary. -0.9
Things doable with this form are also doable with form 2, but it involves
hardcoding the path-to-repository on the server into the external. I.e.,
this doesn't fully solve the "repositories may move" problem, just makes it
a little less severe.
IMO, we really are overdue for some "repository root relative" notation for
use both on the command line, so it seems reasonable to do it for externals
too.
Please clarify "Ew.".
>> Relative form 4: Directory-relative
>> ../../svn/trunk/subversion/tests/clients/cmdline/svntest
>>
>> This form is compliant with RFC 2396.
>> It is stretching the example somewhat, since it would break on tagging
>> or branching cvs2svn, since "tags/foo" and "branches/foo" contain a
>> different number of components to "trunk", but you should get the idea
>> of what the syntax means, nonetheless.
>
> Seeing how fragile this is, esp. WRT tagging and branching, I'm also
> -0.9 on this.
No, this is often requested. Without it, it's impossible to make links
within the scope of a single {trunk,tags,braches} set, and have them work
properly with branching and tagging.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Jan 24, 2005, at 12:18 PM, Max Bowsher wrote:
> Below I propose what might just possibly become the final relative
> externals syntax. Comment, discuss, and then let's implement! ;-)
>
>
> For examples, I will use the external which is present in the cvs2svn
> repository,
> and rewrite it into each of the proposed relative forms.
>
> Existing absolute external:
> http://svn.collab.net/repos/svn/trunk/subversion/tests/clients/
> cmdline/svntest
>
>
> Relative form 1: Scheme-relative
> //svn.collab.net/repos/svn/trunk/subversion/tests/clients/cmdline/
> svntest
>
> This form is compliant with RFC 2396.
+1
> Relative form 2: Host-relative
> /repos/svn/trunk/subversion/tests/clients/cmdline/svntest
>
> This form is compliant with RFC 2396.
+1
> Relative form 3: Repository-relative
> ///../svn/trunk/subversion/tests/clients/cmdline/svntest
>
> The concept of a repository within the URL is fairly unique to
> Subversion, and hence no suitable syntax is expressed in RFC 2396.
> This form takes advantage of the fact that whilst the RFC explicitly
> specifies the meaning of a relative URL beginning with zero, one, or
> two slashes, it is silent on the matter of three or more slashes.
> Therefore I feel this is a good way to accomodate this very useful
> form of relativity into an unused (and unlikely to be used) void in
> the URI standard.
Ew. Given form 2, I think that this is unnecessary. -0.9
> Relative form 4: Directory-relative
> ../../svn/trunk/subversion/tests/clients/cmdline/svntest
>
> This form is compliant with RFC 2396.
> It is stretching the example somewhat, since it would break on tagging
> or branching cvs2svn, since "tags/foo" and "branches/foo" contain a
> different number of components to "trunk", but you should get the idea
> of what the syntax means, nonetheless.
Seeing how fragile this is, esp. WRT tagging and branching, I'm also
-0.9 on this.
I question the importance of covering every possible want for relative
external refernces. Instead, I think that doing 1 & 2, and doing them
right, will provide a much more robust (and comprehensible) solution.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Final(?) Relative Externals format
Posted by Max Bowsher <ma...@ukf.net>.
Michael Brouwer wrote:
> On Jan 24, 2005, at 12:18 PM, Max Bowsher wrote:
>
>> Relative form 2: Host-relative
>> /repos/svn/trunk/subversion/tests/clients/cmdline/svntest
>>
>> This form is compliant with RFC 2396.
>
> How would you distinguish this from a path to a wc in the client?
Not immediately relevant, since externals only operate on URLs.
Some client extended syntax could be invented.
An --url option has been suggested.
>> Relative form 3: Repository-relative
>> ///../svn/trunk/subversion/tests/clients/cmdline/svntest
>
> The use /// is equivalent to svk's usage of // (which the exception
> that in svk you can't specify //../other_repo/
Re: Final(?) Relative Externals format
Posted by Michael Brouwer <mi...@tlaloc.net>.
On Jan 24, 2005, at 12:18 PM, Max Bowsher wrote:
> Below I propose what might just possibly become the final relative
> externals syntax. Comment, discuss, and then let's implement! ;-)
>
>
> For examples, I will use the external which is present in the cvs2svn
> repository,
> and rewrite it into each of the proposed relative forms.
>
> Existing absolute external:
> http://svn.collab.net/repos/svn/trunk/subversion/tests/clients/
> cmdline/svntest
>
>
> Relative form 1: Scheme-relative
> //svn.collab.net/repos/svn/trunk/subversion/tests/clients/cmdline/
> svntest
>
> This form is compliant with RFC 2396.
>
>
> Relative form 2: Host-relative
> /repos/svn/trunk/subversion/tests/clients/cmdline/svntest
>
> This form is compliant with RFC 2396.
How would you distinguish this from a path to a wc in the client?
> Relative form 3: Repository-relative
> ///../svn/trunk/subversion/tests/clients/cmdline/svntest
The use /// is equivalent to svk's usage of // (which the exception
that in svk you can't specify //../other_repo/
Also if I wanted to get to the tags/tag1 would it be:
////tags/tag1 or just ///tags/tag1?
Something else to keep in mind is that Repository-relative urls are
probably going to be used much more often (at least on the command
line) than Scheme-relative repositories, so it might be worth using //
for Repository-relative and /// for Scheme-relative. This would make
// do the same thing in svk and svn.
>
> The concept of a repository within the URL is fairly unique to
> Subversion, and hence no suitable syntax is expressed in RFC 2396.
> This form takes advantage of the fact that whilst the RFC explicitly
> specifies the meaning of a relative URL beginning with zero, one, or
> two slashes, it is silent on the matter of three or more slashes.
> Therefore I feel this is a good way to accomodate this very useful
> form of relativity into an unused (and unlikely to be used) void in
> the URI standard.
>
>
> Relative form 4: Directory-relative
> ../../svn/trunk/subversion/tests/clients/cmdline/svntest
How would you distinguish this from a path to a wc in the client?
> This form is compliant with RFC 2396.
> It is stretching the example somewhat, since it would break on tagging
> or branching cvs2svn, since "tags/foo" and "branches/foo" contain a
> different number of components to "trunk", but you should get the idea
> of what the syntax means, nonetheless.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org