Re: State of Perforce importing.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I had to import quite a big Perforce depot too. And after some struggle it went fine. For case mismatch: http://kb.perforce.com/AdminTasks/SuperuserTasks/CrossPlatfor..erMigration, bullet 10. It requires server access. For a@b and for excluding one p4 path during migration you could use my quick-and-dirty fix (attached). You can easily extend it to include and exclude multiple paths. Then it becomes as flexible as p4 client mapping.

- Dmitry
----- Original Message ----- From: "David Brown" <git@xxxxxxxxxx>
Newsgroups: gmane.comp.version-control.git
To: "Sam Vilain" <sam@xxxxxxxxxx>
Cc: "Git" <git@xxxxxxxxxxxxxxx>
Sent: Tuesday, 18 September 2007 8:49
Subject: Re: State of Perforce importing.


On Tue, Sep 18, 2007 at 07:27:13PM +1200, Sam Vilain wrote:

I'm pretty close to giving a newer one a spin, that actually imports
from the raw perforce back-end files without needing the perforce
server.  I am hoping that this should give a very clean import and will
be very fast and efficient, sending files that share ancestry to gfi in
sequence so that the on-the-fly delta system works.

Unfortunately, this isn't something I'm going to be able to use.  The
Perforce server will remain live, and resides on a machine I don't have
access to.

It could possibly be adapted to use the p4 client (though I'd expect
that to be relatively slow per-revision), and possibly be extended to be
bidirectional as all of the upstream change number information is
recorded, a la git-svn.

I was able to get 'git-p4' to work a lot better by using @all, but it still
has some problems, at least bad interactions with P4.

  - It doesn't use any client spec.  Our P4 server space is a complete
    mismash and has to be fixed up to get a sane directory layout.  For
    example, some revisions have hundred-MB tar files sitting in the root
    directory and I don't want that in the repo.  I also need to exclude
    directories, and in some cases completely rearrange the directory
    layout.

  - Our P4 server is set to be case insensitive.  'git-p4' ignores paths
    that come back from the server that are specified using a different
    case.  Unfortunately, this means that a handful of files just get
    randomly dropped from each revision.

    I tried importing a client path instead of a depot path, but the names
    that come back from 'p4 files' are depot based so none ever match.  I
    end up with a nice revision history of entirely empty trees.

I'm probably going to end up writing an importer that uses an actual client workspace to let Perforce do the client mapping. I'm also going to have to
put some work into some code to clean up the log messages, since most of
our changes have as a first line "New Features:", which makes for a rather
uninformative shortlog.

But, I did learn about 'p4 -G' from git-p4 so that will help in getting
information from the repository.

Thanks,
David

Attachment: 0001-git-p4-Added-exclude-option-and-use-P4-client-nam.patch
Description: Binary data


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux