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

On Fri, 4 Sep 2009, Johannes Schindelin wrote:

Hi,

On Fri, 4 Sep 2009, Sverre Rabbelier wrote:

quoted

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.

If that's how p4 users initialize their working directories, then that is 
the way to go.

And I cannot start to believe that the complicated way you described is 
the common way to initialize p4 working directories, as that would tempt 
the intelligence/enthusiasm of the average programmer.

Perforce is probably the single most popular system for git to import from 
because it is such a monumental pain to use for anything at all that it's 
easier to learn git, write a git importer, and use your git importer than 
it is to actually use Perforce directly.

Of course, it's not really beyond the average programmer to get a p4 
working directory, because whoever is running the server will have 
provided a file to copy and instructions on setting an environment 
variable. They don't know what the magic formula means; they just use it. 
And they only work on one branch until that branch is done with,
and then they throw away that working directory, get a new working 
directory, and never look at the other branch's history again (and 
certainly never track anything across branches). Also, they have p4 
experts who deal with merging branches so that stuff doesn't get lost when 
moving to a new branch. And the experts have scripts built into the 
release process that attempt to insure that things don't get lost. The 
reason that my helper can't have a single location for a repository is 
that the branches of a single project are strewn randomly about the 
namespace, and a proper git import needs to know what to stitch into a 
single repository.

For the matter of where the server is, Perforce supports just having a 
"server:port" value, but if the organization uses this, there's no 
authentication of users possible. Instead, organizations set up an ad hoc 
collection of ssh proxies and give people a string which is the command to 
go through those proxies, because Perforce only knows how to use rsh or a 
command you provide that acts like rsh.

	-Daniel
*This .sig left intentionally blank*