Re: git-p4import.py robustness changes

From: Simon Hausmann <simon@lst.de>
Date: Jun 5, 2007, 07:21 UTC
Message-ID: <200706050922.01431.simon@lst.de>
In-Reply-To: <99C09A45-EACF-43C0-8EF6-85450B109BF6@slamb.org>

On Monday 04 June 2007 09:19:56 Scott Lamb wrote:

Show 23 quoted lines

> On Jun 3, 2007, at 10:54 PM, Shawn O. Pearce wrote:
> > I think writing data to fast-import is much easier than running
> > the raw Git commands, especially when you are talking about an
> > import engine where you need to set all of the special environment
> > variables for git-commit-tree or git-tag to do its job properly.
> > Its a good tool that simply doesn't get enough use, partly because
> > nobody is using it...
>
> Yeah, I'm sold. I read git-p4 more thoroughly and tried it out...it's
> pretty nice. The P4Sync command has a simpler, more trustworthy flow
> than git-p4import.py.
>
> On the Perforce side, I particularly like the use of "p4 print" to
> grab the files instead of "p4 sync". It avoids playing weird games
> with the client - I think nothing good can come of git-p4import.py's
> "p4 sync -k" and symlinks to map multiple branches into the same
> directory, which is not the Perforce way. Makes me nervous that
> what's submitted to git won't be the same as what's in the Perforce
> depot.
>
> I would have thought launching a "p4 print" on each file would be
> horribly slow with the network latency of each request, but...well,
> apparently not.

I've found it to be fast enough for "standard software development". When importing big changes like integrations of an entire branch then it naturally slows down. The workaround me and my colleague have come up with is to combine git-p4 usage with the regular git protocol:

For imports of simple projects from perforce the direct use of git-p4 clone and sync/rebase is good enough.

For big projects we have set up a dedicated (recycled old) machine that continuously imports from the perforce server. That makes the initial clone very fast thanks to the use of the git protocol, it still allows imports from perforce afterwards and when the developer syncs the chances are very high that the dedicated machine already imported the necessary changes/objects from the perforce server and the faster git protocol instead of "p4 print" on a lot of files can be used.

In order to avoid that machine constantly polling the p4 server we've come up with a neat little trick by adding a change-commit trigger on the p4 server that consists of a little perl script that just sends a single udp packet with the latest change number as notification to the git machine, which upon reception imports then.

That is why git-p4 sync/rebase call "git fetch" by default (configurable through config key) if there is an origin remote present.

> Maybe I'll work up git-p4 patches for subcommand error handling, like
> my git-p4import.py ones. And fix some style - seriously, who puts
> semicolons at the end of Python commands? *grumble*

I'd be more than happy to apply style patches. I'm not a very experienced python programmer and I admit that I certainly lack the style there :)

Simon