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

From: Simon Hausmann <simon@lst.de>
Date: Jun 11, 2007, 18:42 UTC
Message-ID: <200706112042.16331.simon@lst.de>
In-Reply-To: <81b0412b0706110844i12ebe52m21735815cc06effa@mail.gmail.com>

On Monday 11 June 2007 17:44:04 Alex Riesen wrote:

Show 10 quoted lines

> 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, but the revision range can be specified in p4-like syntax as part of the depot path. For example

	git-p4 clone //depot/path@12,435

to import from revision 12 up to 435. The revision range is more or less passed directly to "p4 changes", with the exception of "@all".

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

Show 5 quoted lines

> The way Perforce handles branches and directories leads to
> the problem that it actually cannot cleanly support neither of
> them, and it is very hard to untangle a big repo which
> historically has had many projects living in it.
> Especially if some idiot actually tried to "do branching".

I agree, even with a lot of discipline it's very hard to do a 100% accurate import with logical branches.

The environment I'm working in is not too big and fairly liberal and reasonably disciplined. I'm using p4 branch mappings to "map" some branches from perforce to git, which for sure isn't perfect but works overall fine. Of course that doesn't cover p4 integration changes, but just for tracking multiple "logical" p4 branches it works great (for me at least :).

> 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 :)

Simon