Re: State of Perforce importing.

From: Reece Dunn <msclrhd@googlemail.com>
Date: Sep 18, 2007, 17:53 UTC
Message-ID: <3f4fd2640709181053t70b7abcdi2c4eaf67e7b75338@mail.gmail.com>
In-Reply-To: <20070918154918.GA19106@old.davidb.org>

On 18/09/2007, David Brown <git@davidb.org> wrote:

Show 11 quoted lines

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

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.

Show 7 quoted lines

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

Show 6 quoted lines

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