git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: State of Perforce importing.

From
David Brown <git@davidb.org>
Date
Sep 18, 2007, 15:49 UTC
Message-ID
<20070918154918.GA19106@old.davidb.org>
In-Reply-To
<46EF7DD1.9090301@vilain.net>
On Tue, Sep 18, 2007 at 07:27:13PM +1200, Sam Vilain wrote:
Show 5 quoted lines
>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

Previous: Sam VilainNext: Reece Dunn
Message 4 of 19 in “State of Perforce importing.”
  1. David BrownSep 17, 2007
  2. Simon HausmannSep 18, 2007
  3. Sam VilainSep 18, 2007
  4. David BrownSep 18, 2007
  5. Reece DunnSep 18, 2007
  6. David BrownSep 18, 2007
  7. Sam VilainSep 19, 2007
  8. David BrownSep 19, 2007
  9. Sam VilainSep 19, 2007
  10. Reece DunnSep 19, 2007
  11. Dmitry KakurinSep 20, 2007
  12. David BrownSep 18, 2007
  13. Sam VilainSep 19, 2007
  14. David BrownSep 19, 2007
  15. Simon HausmannSep 19, 2007
  16. David BrownSep 19, 2007
  17. Reece DunnSep 19, 2007
  18. David BrownSep 19, 2007
  19. Reece DunnSep 19, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.