On Mon, Aug 3, 2009 at 13:30, Sam Vilain<sam@xxxxxxxxxx> wrote: > On Mon, 2009-08-03 at 10:47 +0200, Alex Riesen wrote: >> Is it an import-once tool, or can the process be restarted? (because it looks >> like the script needs a complicated setup). > > It's fully restartable. Not only that but it uses transaction > protection to make sure that its internal state doesn't get corrupted > when performing the various options. "varios options"? Operations? As when working on a live server? Aren't P4 changelist numbers always increasing? Or you mean the protection against multiple running instances of p4raw, so it is also parallelizable? >> Can it be used from a client machine? >> And more importantly: >> can the branches be found from incomplete history, >> restricted by path and changelist range? (because, in a corporate >> setup, clients seldom have full access to all data). > > No, it's server only. ... Darn. I hoped it wasn't. Can't play with it, then. > ... I think I did get around to implementing not having > to go through all the stages for branches you didn't care to import. It's > difficult though, the stage which correlates those thousands of 'integrate' > records is never going to be fast. Maybe if it is done locally, it can be improved? You seem to use the Postgre for lookups, right? > Be prepared to tune your postgres - add lots of shared_buffers and > sort memory if your project is as large as Perl. Mine isn't, but it is thrown on a server with a lot of others. Some branched off mine, some integrate it, some just copied and re-introduced into repository (these will probably worked with manually forever). There is also a small problem of different P4 servers, hosting code from the same project (they pull different repos together on client, imagine that!) And all of them go back for 5-6 years, so it is kind of largish (not to mention a mess of binaries). Some branches I hope to merge back. I do that already, but it is a lot of manual work (I use that git-p4-import.bat I posted early, which only can import a sequence of changelists with files they touch). That's were I hoped your project could help. I thought, if I pull in all the needed changelists (selected by path/CL), there may be a way to recreate a mergeable history out of this dump. At least, one involving less labor then I have to do now. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html