Re: [PATCH 5/8] Add a config option for remotes to specify a foreign vcs

From: Jakub Narebski <jnareb@gmail.com>
Date: Aug 13, 2009, 22:00 UTC
Message-ID: <200908140000.43185.jnareb@gmail.com>
In-Reply-To: <7vocqkydum.fsf@alter.siamese.dyndns.org>

On Wed, 12 August 2009, Junio C Hamano wrote:

Show 29 quoted lines

> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> Jeff King <peff@peff.net> writes:
>>
>>>   1. Is there some other syntax that _doesn't_ have this breakage
>>>      but that similarly helps the "vast majority of Git users".
>>
>> Well, proposed possible syntax was:
>> 1. <vcs>:<repository location>
>> ...
>> 2. <vcs>::<repository location>
>> ...
>> 3. <vcs>+<repository location>
>>
>>    e.g.
>>
>>      svn+http://svn.example.com/project
>>
>>    but
>>
>>      http+svn://svn.example.com/project
>>      svn+path/to/repo
> 
> I do not think these are valid examples to demonstrate that 3 is bad.
> 
> We do not have (and we will not create) "http+svn://" native transport, so
> the former can only mean "Feed 'svn://svn.example.com/project' to the vcs
> helper whose name is 'http'".  Similarly I do not see any way to read the
> latter other than "Feed 'path/to/repo' to 'svn' vcs helper".

And not "Use 'svn+path/to/repo' as local filesystem path to repository? On the other hand you can always use here './svn+path/to/repo'

Show 10 quoted lines

> Double-colon (your 2) is also workable.  It probably is slightly better
> than plus because it does not have to grandfather "git+ssh" and "ssh+git"
> and that would be beneficial for requiring less complexity in both code
> (i.e. special case logic) and more importantly in mental burden to the end
> users (i.e. '::' would stand out more than '+' and clearly different from
> traditional git URLs in all cases).
> 
> As Jeff said (your 1.), a single colon ':' has a rather bad ambiguity
> between <vcs> and hostname part in the existing scp-style repository
> naming.

Also double colon is better for scp-like repository location, as e.g.

  svn+example.com:path/to/repo

might be 'path/to/repo' on 'svn+example.com' host; there is no "escape" mechanism like for './svn+path/to/repo' relative path. On the other hand unescaped ':' cannot be present in hostname, therefore the following is unambiguous:

  svn::example.com:path/to/repo

But on another hand svn+http://svn.example.com/project/trunk/ looks IMVHO better that svn::http://svn.example.com/project/trunk/

-- 
Jakub Narebski
Poland