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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 4 Sep 2009, Johannes Schindelin wrote:

> Hi,
> 
> On Fri, 4 Sep 2009, Sverre Rabbelier wrote:
> 
> > 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.
> 
> 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*

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]