Recommended Perfarce (or other?) usage to evaluate Mercurial workflow

Question

[NOTE: "Perfarce" is the name of a Mercurial extension for integrating with Perforce: https://www.mercurial-scm.org/wiki/PerfarceExtension]

We're starting to evaluate Mercurial for a project that's currently stored in Perforce. Rather than abandon the P4 depot and make all changes in Hg, we'd like to primarily work in Hg and push changes to P4 periodically. There's a chance some developers will continue working in Perforce during this evaluation, but other than that we want to evaluate the workflows that DVCS makes possible such as pulling from one dev's repo to another.

I've tried the Perfarce extension, and it looks like a great way to use Hg as an advanced P4 client with more granular local history. However, when I use Perfarce to check out the same tree on two different machines, I get two Mercurial histories with different changeset IDs. It looks like the only way to share changes this way would be to go through the P4 depot.

Are there other options for keeping developers' repositories synced with P4 without making them incompatible at the Mercurial level?

Answer 1

Honestly - this sounds like a situation that can be the cause for nightmares. Here is how I would approach it to minimize some of the risk and pain:

• Setup the Perforce workspaces to "allwrite" such that Perforce won't interfere with Hg as much.
• Use a single P4 workspace to sync changes from the depot down to a mercurial repository (and from hg back to the depot), then do your mercurial push/pull work from it. Treat it kind of like the master repository on GitHub or Bitbucket.
• Using the one-true-workspace sync changes back to Perforce by using the "reconcile offline work" feature of P4V and make sure to carefully review the changelists (you don't want to submit the .hg directory).

With some discipline you should be able to avoid some pitfalls, though it certainly isn't an ideal path forward. I don't think there is a single bullet that will allow you to seamlessly keep your changes properly mirrored across all the different repositories and allow everyone to just work as usual.