thestar@xxxxxxxxxxxxxxxx wrote on Tue, 09 Dec 2008 21:25 +1100:
> I couldn't use git-p4 on my system because I kept running out of memory,
> and I didn't like the workflow it imposed.
> Also, it had various other issues with the repo I was trying to use,
> mainly because it is not an ideal repository, however those are
> (generally) the fault of the particular repo I was using, and not
> git-p4. (Which is an excellent script by itself).
>
> This script is severely crippled in that it doesn't (yet) allow one to
> contribute changesets back to perforce, however it manages to read from
> perforce with:
> * No need to rebase.
> * Mangling of file names. (Especially with regards to case sensitivity).
> * Tagging of revisions with the perforce changesets.
> * Ability to handle branches with spaces in the name.
> * Ability to pretend that perforce doesn't exist. (That's the plan,
> anyway).
> * Be extremely memory efficient. It does NOT require as much memory as
> does git-p4, even when the size of the change is large.
> * Be easy to manually modify the repository, particularly if bad things
> happen.
I like how your script imports one change at a time, as the initial
import using git-p4 here does indeed get close to exhasting virtual
memory, but I'm running into a different limitation with p4c.
The command:
p4 -G changes -l -t
is adminstratively limited to a paltry six-digit number, and
produces only an error message.
The other feature I need is the ability to use a client
specification. We merge together 40-odd different chunks of //depot
into a single checked-out client, and use some other number of
"-//depot/..." rules to exclude some parts of the full depot.
If I hack p4c to limit the changes with "-m 10" or so, then things
are a bit better in that I get two objects (changesets) but no
diffs. Had to hack the on_branch() code somewhat, in that no form
of --branches seemed to produce an "interesting" changeset by your
definition. Could be my lack of understanding here.
If you think you want to handle client specifications, and can think
of a way around the "p4 changes" limitation, I'll be happy to poke
at your next version. Perhaps I'm not in your target audience,
though. I don't necessarily need to have a full git history of the
entire p4, but this seems to be a fundamental part of your approach.
-- Pete
--
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
