perforce gateway

[Steve Borho]

On Tue, Dec 15, 2009 at 11:56 AM, Mads Kiilerich <mads at kiilerich.com> wrote:
> On 12/15/2009 05:41 PM, Steve Borho wrote:
>>
>> Hey folks,
>>
>> I'm contemplating writing a set of scripts to serve as a gateway
>> between Mercurial and Perforce, and was hoping for some early feedback
>> to tell me if I'm heading towards a dead end.
>
> Nice plan - good luck!
>
>> Basic Use Case:
>>
>> 1) Your day job uses Perforce, so all of your changes must eventually
>> make it into the p4 repository, else your boss can assume you are
>> doing no work.
>>
>> 2) You would like to use Mercurial for your day to day commits and
>> periodically merge back completed work into perforce.
>>
>> 3) You would like to keep an accurate history of your p4 merges within
>> your hg repository
>
> Perforce merges are very different from Mercurial merges, so it is simply
> not possible to have an accurate history of Perforce merges in Mercurial.
>
> Mercurial merges are very clean; a merge always merges changesets
> completely.
>
> Perforce can merge on file level, and it also allows cherry-pick merges of
> one change without its ancestors. A "revision" from another branch can thus
> be "merged" to a branch several times, and still the merged revision isn't
> an "ancestor" of "tip".
>
> So an accurate history isn't possible. You can probably get a decent
> approximation, but be careful if you try to merge branches converted from
> Perforce.

'p4 merges' in this context only means the merging of your mercurial
work into perforce.  I guess 'hg->p4 merges' would have been more
clear.   I have no intention of trying to describe perforce
integrations inside of Mercurial.  That would be quite futile.

What I want specifically is for hg convert to tag these 'hg->p4'
commits as merge revisions so the hg merge machinery properly uses it
as a new common ancestor for new changes.

>> # submit this change with a comment like:
>>
>> merge from branch dev
>> Parent changeset ##############
>>
>> Now we need some logic in the conversion script.  When it converts
>> this perforce commit, it needs to set the second parent to the node
>> hash in the commit message.   Now when the user pulls from the
>> gateway, they get a Mercurial changeset that actually merges their dev
>> branch with the p4trunk branch and they are free to continue working.
>
> IIRC the p4 commit will tell you which perforce changeset number the commit
> created. The existing hg changeset could be tagged with the perforce
> changeset number, so that the following incremental convert from perforce to
> Mercurial can (be taught to) reuse that changeset. Or perhaps the convert
> could be done immediately while it knows how they are related.

I want all p4 commits to show up in the p4trunk branch, so this
'hg->p4' merge p4 commit should be shown in the mercurial conversion
as a changeset on the p4trunk branch with the second parent reference
the 'dev' branch head that was merged.

> A pragmatic approach like this could perhaps be used for working with other
> VCS too, so perhaps it could be built into hg convert?

I imagine it could.

--
Steve Borho