Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case

On Fri, 4 Sep 2009, Sverre Rabbelier wrote:

Heya,

On Fri, Sep 4, 2009 at 21:05, Daniel Barkalow[off-list ref] wrote:

quoted

Some foreign vcses, including the only one I ever personally use, do not
have URLs, and require a bunch of options and paths to specify a
repository. I don't want to have to use:

       url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...

Btw, doesn't p4 have these config files that you can download that
contain the configuration? In that case
'p4://example.org/p4/main-development.configfile' would be very
convenient.

The only thing I know of which you might be thinking of is "client 
specifications", which are like git superprojects. They're almost certain 
to only specify one of the multiple locations that you want to have in the 
same repository; the multiple locations are the paths you want to treat 
as branches, and the client picks one branch of each project and places 
it in some non-branch-specific location relative to other projects. (Of 
course, someday I might want to support importing a client specification 
as a git project with submodules, but it's got the same issues as 
svn::externals without revision specifications seems to).

In any case, p4 doesn't have any easy generic way to specify how to 
contact the server, and doesn't have anything client-side.

Regardless, I do think there should be some way to specify all this
outside of the url, but to me that's secondary. I think the primary
usecase is/should be cloning from some url in the form of
'hg://example.org/foo', rather than 'http://example.org/some-hg-repo'
or 'p4://.......', since those are both exceptions (the former being
an ambiguous url, and the latter being a non-url). Now I do understand
if you don't want to spend your time on implementing the specialized
url support since it doesn't scratch your itch, but at least your
series shouldn't impend supporting that in the near future.

I'm pretty sure that this series makes your primary usecase slightly 
simpler to support, because it no longer is expected to handle the 
ambiguous "http://" class of URLs.

	-Daniel
*This .sig left intentionally blank*