Re: [PATCH/RFC 2/2] git-p4: Add complex test case for branch import

> On Tue, Aug 23, 2011 at 3:27 AM, Pete Wyckoff <pw@padd.com> wrote:
> > I think I understand the problem now, and have a small test case
> > to see what's going wrong.  Your solution is definitely
> > sub-optimal.  :)  Is there anything that can be done with
> > --import-marks and --export-marks?
> 
> Don't know if you agree, but I think it would be better to keep git-p4
> from storing extra files in the filesystem. And, as far as I understood,
> these two options require extra files.
> But I don't think marks would help us that much. We already have
> something similar: the changelist number in the commit log. The big
> problem is that P4 does not store a pointer to the previous changelist.

> > Could you guess at the branch point using p4?  I.e. for each file
> > in the new branch, grab the change that caused its most recent
> > revision (the #xx part).  Pick the max of those changes.  In git,
> > find the commit whith "change = ..." that you just discovered.
> > That's the parent.
> 
> Yes, I think this would work. Nevertheless, I would prefer not to do so
> much pooling on the P4 server because when we're in a remote location in
> regards to the P4 proxy server this kind of command becomes rather slow.
> And if the branch has many files this may become cumbersome.
> 
> > Even this won't be perfect, and I'm not even sure if it's less
> > icky than diff-tree.
> 
> From what I can see, the two possible solutions would be:
> 
> a) Running a "filelog" on all files. This may become slower when the
>    branch has lots of files. There's also the problem in needing to
>    contact the P4 proxy server every time.
> 
> b) Using diff-tree. This will be slower if the original changelist is
>    very far from the latest one, but has the advantage of being run
>    locally. It has the disadvantage of not having an apparent
>    compatibility with fast-import.
> 
> In my personal point of view, diff-tree solution still looks better, if
> it weren't for the fast-import issue. Now if we could just figure out
> how to overcome this issue...