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

Hi,

On Fri, 4 Sep 2009, Daniel Barkalow wrote:

On Fri, 4 Sep 2009, Johannes Schindelin wrote:

quoted

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.

That is what we need to optimize for, then.

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.

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