On Fri, 4 Sep 2009, Sverre Rabbelier wrote: > Heya, > > On Fri, Sep 4, 2009 at 21:05, Daniel Barkalow<barkalow@xxxxxxxxxxxx> wrote: > > 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*