Re: Asking again... [Re: how to properly import perforce history?]

Alex Riesen wrote:

Scott Lamb, Mon, Jun 11, 2007 23:20:43 +0200:

quoted

quoted

quoted

quoted

 git-p4 clone //depot/project/path [libs/project/path] [rev-range]

I'm not sure I understand the libs/project/path part, ...

Your client contains the mappings. It defines how the pathnames on the
p4 server relate to that on your computer. In the example above file
from the depot path //depot/project/path can be found in the directory
of the p4 client in the subdirectories libs/project/path.

git-p4 doesn't even use a p4 client, ...

I didn't say: "using p4 client, figure out where to put the files".
I said: _here_ is the mapping, put the files where I told you to.

No, you didn't say. The words you used would make equal sense with "the 
tool should look for //depot/project/path in the working copy at 
libs/project/path".

quoted

quoted

quoted

Han-Wen implemented also support for importing multiple depot paths at 
the same time (and tracking them in one git branch).

And where does he put the depot paths? As they are in depot? How does
this corelate to the setups done by genuine P4 users (the poor souls)
where the mappings are not always 1-to-1 right from the root? Or you
haven't got any?

Could you give a concrete example of what you have and what you are 
trying to produce?

Get the p4 file //depot/project/file and put it into git as
libs/project/file.

Okay. Keep in mind that you're the first person to find this important.

quoted

quoted

quoted

The environment I'm working in is not too big and fairly liberal and 
reasonably disciplined.

You must be very strange environment indeed. Carefully balanced.

Not that strange. My company's setup is pretty simple, too. The project 
I'm working on just uses has each branch under 
"//depot/project/BRANCH/...".

It is not a branch (as a "line of development"). It is merely a
directory with server-side backup. Why do people continue call them
branches, I wonder...

You're being deliberately dense, but I'll explain anyway.

We have several branches of our code. We keep each one in Perforce under 
//depot/project/BRANCH/... with appropriate integration history between. 
We follow the best practices outlined in the Perforce manual. [1] We use 
the same terminology as defined in the Perforce manual.

 From your comments, I would guess that you have badly mismanaged your 
Perforce tree. Since the other people working on the tool apparently 
have not, you may have to do your own work to migrate away.

Subversion has a very similar model to Perforce (the main differences 
being that svn does not track merge history and does not have a separate 
tag system). I have a Subversion repository in which I did not follow 
the recommended practices for branching. Who do I blame for that? Me. 
Who will fix it? Hopefully me. I may ask for help, but I'll do so with a 
better attitude than you.

quoted

Maybe your environment is the odd one?

Just what do you think is a client view? Ever wondered what the
right-hand side of lines in the "View:" section is for?

I know what client views are, and I know what they are capable of. I can 
say the same thing about symlinks. Is an importer tool broken if it does 
not follow a bizarre reorganization of the source working copy through 
symlinks?

[1] - 
http://www.perforce.com/perforce/doc.072/manuals/p4guide/06_codemgmt.html#1065698

-- 
Scott Lamb <http://www.slamb.org/>