Local commits pushing to a central server

Question

At work we use perforce and are encouraged to make regular commits to it (something I am fine with). However, I'd like to run something like mercurial so I can locally commit stuff that is work in progress and doesn't necessarily compile/run and then from this do my regular commits to the central perforce server.

My question here is kind of two-fold, first off, does anyone know how well Visual Studio would cope with multiple source control bindings (ideally I want everything to be as autonomous as possible - hey, I'm lazy:))

And secondly, are there any tools available that would allow me to do something as simple as "Check current head of mercurial repository in to perforce".

I seem to recall GIT allows you to do something similar to this, and I'm not entirely against trying it out.

If I've missed out anything obvious or am thinking about this in entirely the wrong way, please feel free to berate me ;)

Cheers

Answer 1

In my opinion, what you want is different branches instead of multiple SCM systems. If you want to have your playground where you can submit work-in-progress, create a development branch off the main-branch in Perforce. You can update that on a regular basis with stuff that others submit and integrate your changes back to main once you are satisfied/done.

This also eliminates the question about how well VS would cope with it.

Answer 2

The interest of your idea is not so much in the private commits as it would be in the "off-line development": Mercurial or Git would allow you to work even if not connected to the central Perforce repository.

But regarding branching, they are easier to create or merge with Hg or Git, so it could be an idea.
The principle would be to create your Hg or Git repo right in your Perforce workspace.

This article using mercurial with perforce (or some other centralized vcs) does illustrate a similar approach:

If the code is already in perforce, I'll pull down a copy and hg init a local repository; otherwise I'll init using mercurial and check into perforce later (typically this is for a spike).
The I'll do some work, committing as I go to mercurial.
My perforce commit tends to be a rollup of smaller hg commits, alternatively if I want to track changes specifically I'll check in the individual hg commits by rolling forward the history using "hg update" (some more on this below).
Don't commit the .hg folder into perforce by the way

Answer 3

Git comes with a git-p4 front-end that allows you to create a new git repository that tracks all or part of a Perforce sub-tree. (Complex client workspaces are not supported, last I checked). git-p4 is normally found in the contrib tree and may or may not come with your Git install, or you can grab a recent version here, from git.kernel.org. This script requires Python.

Essentially, you git p4 clone your upstream //depot/path and then can git p4 sync to pull down new changes into your current branch, or git p4 rebase to rebase your current branch on top of the upstream Perforce path. If you have a separate Perforce workspace adjacent to your git repository, you can then git p4 submit. (I use a separate internal tool at VMware for submitting to our Perforce servers, so I haven't used git p4 submit though.)

Unfortunately, I don't know how well VS deals with git or git and Perforce simultaneously. My guess is that any VS integration does not deal with the Perforce side of git-p4, but you can do all your normal git operations the way you normally do and just use a shell to call git-p4.bat or some such to do your Perforce operations.

Another option is to simply have a git (or Mercurial) repository initialized right in your Perforce workspace. Here is an example of someone who does this with Mercurial.