perforce gateway

[Steve Borho]

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.

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


Preconditions:

To start with, we assume that you have a machine that is running a
conversion script (perhaps hg convert), converting perforce changesets
into mercurial changesets and that this is automated so you can pull
from this repository to get the latest perforce commits.  p4
changesets are added into a named branch, say 'p4trunk'.  We'll call
this the gateway repo.

In your personal Mercurial repository, you use a named branch to track
the changes you are making.  Let's call this 'dev'.


Merging with Perforce:

At the point you want to merge your accumulated changes back with
Perforce, you ensure your dev branch tip is an ancestor of the tip
revision of the perforce branch (aka, do a pull + merge), run your
smoke tests, etc, then push to the gateway repository.

The gateway repository will have a p4merge script (or extension).  The
syntax would be simple:

% hg p4merge dev

It would perform the following steps:
# validate dev has one head, and it is an ancestor of most recent p4 commit
# run 'hg status p4trunk:dev' to get accumulative list of modified,
added, removed files on dev branch
# run 'p4 edit' on modified file list
# run 'p4 rm' on the R (removed) files
# use 'hg revert -r dev' to get the modifed and added files from the dev branch
# run 'p4 add' on the added files
# 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.

Once this was all functional, you could automate the gateway to
periodically run convert and check for heads to merge.  It also has
the nice quality of allowing a single gateway to be shared by many
Mercurial users.  They could each have their own named branch, or they
could collaborate on a shared named branch.  I think this general idea
could be used for any other VCS that does not have hg write-back
support, like hgsubversion supplies.

Note that we can't merge the p4 commit and conversion steps together
since there is always the possibility someone will commit to p4 while
you are trying to commit the merge.  Since the merge commit (to p4)
can still succeed, you won't know about the extra intervening commit
until you run the conversion script again.  And that is why I'm
storing the parent hash in the commit message.

Comments?

--
Steve Borho