Re: [PATCH] git-p4: Fix support for symlinks.

[Scott Lamb <slamb@slamb.org>]

Brian Swetland wrote:
> One observation on git-p4 -- it's a little memory hungry when processing
> large syncs.  I haven't tried incremental syncs on top of the initial
> one though -- if it's only the initial that's expensive it's not that
> big a deal.
> 
> It seemed to top out around 988MB resident.  The branch I was importing
> is about 562MB when checked out and the resulting git repository is
> about 175MB.

While importing each change, I think git-p4 puts into memory two copies 
of the contents of all changed files, one in p4CmdList and one in 
readP4Files. (That's the raw contents, not just the delta.) I don't 
think there's any fundamental reason it couldn't stream them instead.

So incremental syncs may or may not take less memory. If the first 
change imports a huge project and no subsequent change ever touches all 
those files at once, then yeah. But if, say, you periodically change the 
copyright dates in all files in the repository, you'll have this memory 
usage whenever syncing such a change.

As long as we're listing git-p4 complaints, here are a couple of mine:

1) coding style. *self-nag* Simon Hausmann mentioned he was happy to 
accept patches...and I made one up a while ago; I just need to do a 
merge and final check that I haven't broken anything before sending it off.

2) it breaks on tempfile purges. My previous employer has these in their 
repository, and I think for the moment they're working around it by 
treating a "purge" as a "delete". If I read the Perforce documentation 
right, though, only the latest version of a tempfile's contents is kept 
in the repository anyway. Their history can't be captured accurately, so 
the proper thing is probably to omit tempfiles entirely. (And deleting 
files when they become tempfiles and creating files when they become a 
normal type.)

Best regards,
Scott

-- 
Scott Lamb <http://www.slamb.org/>