Re: git-p4import.py robustness changes

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

On Jun 3, 2007, at 10:54 PM, Shawn O. Pearce wrote:

quoted

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