Re: State of Perforce importing.

On 18/09/2007, David Brown [off-list ref] wrote:

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

quoted

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.

I use git-p4 in the same way. The best approach would be to have both
tools and to use whichever one best matches your needs.

quoted

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.

I have also seen this.

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

The directory exclusion you could do the other way, if git-p4
supported multiple directory paths.

The main issues with using client workspaces is that they require you
to use `p4 sync`, whereas git-p4 uses `p4 print` and that they may
change as the repository changes, but Perforce does not track these
changes.

That said, something like what workspaces are doing (allowing you to
specify multiple paths and where they are to go) would be useful.

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

It is worse than this. If you have:

    p4 integrate foo Foo
    p4 delete foo

then git-p4 will completely remove the file foo from the repository! I
reported this a while back, but did not get a reply.

This is something I want to fix, as doing an '@all', rebase or sync is
broken in this case when dealing with renamed files as above when
importing a repository on a case insensitive system.

The alternative is to do the importing from Perforce on a Linux
machine and then clone/pull/rebase from it on a Windows machine.

     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.

Ideally, git-p4 should bail out here with an error about the path
needing to be specified as a depot path.

I'm probably going to end up writing an importer that uses an actual client
workspace to let Perforce do the client mapping.

As eluded to above, I want to extend git-p4 to support a
workspace-like importer map file to use instead of a specific depot
path (with a single depot path being supported as well for backward
compatibility and simplicity if the repository you are importing from
has a simple layout).

There is no need to create yet another Perforce importing tool, git-p4
works well in most cases. If we focus on improving git-p4, extending
it to support the functionality mentioned here, fix the issues that
there are with it, then that will be more beneficial to the community
as they will not have to learn another tool with a different set of
bugs and issues.

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.

I would not do that. It is a good idea to keep the original log
messages, even if it does make for an uninformative shortlog. Look at
some of the CVS/SVN imported logs!

- Reece