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

[Scott Lamb <slamb@slamb.org>]

Alex Riesen wrote:
> Simon Hausmann, Mon, Jun 11, 2007 20:42:12 +0200:
>> On Monday 11 June 2007 17:44:04 Alex Riesen wrote:
>>> On 6/11/07, Simon Hausmann <simon@lst.de> wrote:
>>>> *plug* You could try with git-p4 from http://repo.or.cz/w/fast-export.git
>>>> . It should be just a matter of calling
>>>>
>>>>         git-p4 clone //depot/path
>>> Can I suggest you add a target directory mapping to your tool?
>>> Something like:
>>>
>>>   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, so the result is simply as it was 
on the server. It just does a "p4 print" on depot paths.

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

> 
>> 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/...". Maybe your environment is the odd one?

>>> And, BTW, don't you have a small problem with filenames with
>>> spaces and quoting?
>> I'm not aware of any problems. For example in our depot we have filenames with 
>> spaces in them and they appear just fine in my git import. Did you run into 
>> any specific case? It could very well be that there's a bug somewhere that 
>> I'm just not hitting myself, so I'm curious :)
> 
> No, I just looking at the source. Does python have some magic for
> running programs with system() when passed a format string? Like here:
> 
>         for f in filesToAdd:
>             system("p4 add %s" % f)
>         for f in filesToDelete:
>             system("p4 revert %s" % f)
>             system("p4 delete %s" % f)
> 
> BTW, sometimes you quote the names, but obviously wrong (think about
> filenames containing double quotes):
> 
>                 system("p4 edit \"%s\"" % path)
>                 editedFiles.add(path)

No, there's no magic. I can't imagine how these could work properly with 
complex filenames. They also don't do any checking of return values. I'm 
planning on sending in patches to make git-p4 use the Python subprocess 
module to do this better (as I did for git-p4import.py). It might take 
me a while to get to that item on my todo list, though - rather busy at 
work right now.

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