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

From: Scott Lamb <slamb@slamb.org>
Date: Jun 11, 2007, 23:41 UTC
Message-ID: <466DDDBA.6060500@slamb.org>
In-Reply-To: <20070611231648.GC4649@steel.home>

Alex Riesen wrote:

Show 11 quoted lines

> Scott Lamb, Mon, Jun 11, 2007 23:20:43 +0200:
>>>>>  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".

Show 11 quoted lines

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

Show 11 quoted lines

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

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