I've been using the Perforce version control system since somewhere around 1999. That's when one of the engineers at the startup I was a part of suggested that we consider this new VCS system he read about instead of the (oh the horror) Visual Source Safe solution we had inherited from the company we spun out of.
At the time, merge oriented version control was new to us (our experience had been with lock oriented version control). Perforce the company did (and still does) and excellent job of explaining its technology and the strong philisophical underpinnings behind the design choices they made. That, coupled with excellent support duing the eval period (and afterwords) reasonable pricing and very solid software made it easy for us to switch to Perforce -- a decision we never regreted.
Four years ago when I joined a small company that was still using CVS it was remarkably easy to help effect a fairly seamless change to Perforce for much of the same reasons.
These days, though, I look a bit longingly at the distributed version control systems like darcs, mercurial, git and bazaar. To my mind, based somewhat limited experimentation, these distributed systems provide a certain "nimbleness" to the working envionment that dynamic languages provide. In a way, they are to Perforce what Python and Ruby are to Java (though that's an analogy that'd probably break down fairly quickly).
What I wonder is this. If some company with the same "sensible, reliable" style that Peforce had 10 years ago (and still has) delivered a distributed version control system that was as solid, fast and reliable as Perforce, with the same level of documentation and support would Perforce be in trouble? I have to think they would, though the "sensible" part of that proposal is probably less likely than the technical part. Perforce is s company that essentially does one thing, and one thing very well. I admire them for that. But their product hasn't really changed meaningfully in the 8 years that I've been using it, which I think exposes them to some risk.
Which gets me to my wish. The biggest problem with Perforce is that despite several workarounds, it's a pain in the neck to use if you don't have a live reliable connection to the central depot. For remote work, which I do a fair bit of, this means that I either always have my VPN fired up (with the associated cheerful tromping of my typical network environment) or I use one of those less than satisfactory workarounds. And If I happen to be in a cabin on a lake in Maine with no Internet connectivity at all, I'm really out of luck.
I want to be able to take a Perforce client and treat it as (or export it to) a distributed VCS work space. That means that I'd be able to maintain a revision history within my client that's independent of the main repository. That allows me to setup up checkpoints before some risky bug fixing maneuver. I want to be able to push and pull my workspace to colleagues. This allows me to easily set up collaborative efforts or shared bug hunts easily with messing with a lot of repositories. Then, when I've pulled all the merges I want into my initial workspace, I want to be able to commit it back to the Perforce depot. I'd be willing to live with a system where I can only peer with workspaces that were pulled from my initial workspace (dealing with the merge paths that could result from peer merging and then submission from multiple work spaces is too twisty for my head).
I know there a few foo2p4 and p42foo scripts out there that attempt to provide something like what I've described. But none of them seem to be quite ready for prime time (yet) and besides, I want a supported, rock solid solution.
If Perforce doesn't provide something like that, I think someone else will.