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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sep 4, 2009, 22:36 UTC
Message-ID: <alpine.DEB.1.00.0909050023240.8306@pacific.mpi-cbg.de>
In-Reply-To: <alpine.LNX.2.00.0909041750390.28290@iabervon.org>

Hi,

On Fri, 4 Sep 2009, Daniel Barkalow wrote:

Show 35 quoted lines

> 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@iabervon.org> 
> > > 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.

That is what we need to optimize for, then.

Show 12 quoted lines

> 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.

And why not having the different branches which are strewn randomly about the namespace as separate remotes for a Git repository? After all, the average p4 user will be wanting to work on _one_ branch, as you so aptly described.

Show 6 quoted lines

> 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.

That explains a tiny part of the long path you provided, but certainly not all (I am especially curious what /bin/true thinks it's doing in that URL).

If what you said about ssh is true, then it should be the same type of invocation everywhere, and it should certainly be very easy to provide a shortcut for that URL; no need for the _user_ (who could not care less how ssh happens to be called) to remember.

Something like "git clone p4::ssh://p4ssh@projects/foo/bar-1.0/..." should become a very easy and intuitive way for the average programmer to clone a p4 branch into a Git repository.

Should the developer ever need to work with another branch of the same project, very easy:

	$ git remote add -f bar-1.1 p4::ssh://p4ssh@projects/foo/bar-1.1/...
	$ git checkout -b my-1.1 bar-1.1/master

Now, I am not married to having more than one remote for multiple branches, but there is _no_ reason why this has to be done at clone time, if the average p4 user does not do that either. You can always teach git-remote-p4 to behave sensibly and ask the user to

	$ git config --add remote.origin.fetch \
		+/foo/bar-1.1:refs/remotes/origin/bar-1.1

Note, these are two alternative suggestions. I am not trying to decide what is better here, but I am convinced that both options are more intuitive than the "vcs" variable.

Ciao, Dscho