June 3, 2011

P4Sandbox Lets the Devs Play

MERGE User Conference

Is stealth good or bad? Apparently, it depends on who's checking out files. About a year and a half ago, Perforce began exploring how to unplug Perforce to function in a distributed manner, where connectivity was spotty or privacy made sense. P4Sandbox's Private Local Branching lets developers work on their own local copy of a project without the isolation of a traditional DVCS.

While the response was overwhelmingly positive, a wave of laughter swept the audience when someone asked presenter Alan Teague, integrations and plug-ins technical director for Perforce, if notorious cowboy coders could be blocked from using P4Sandbox.

Zig Zichterman and Alan Teague
Zig Zichterman (left) and Alan Teague (right).

The answer is yes -- but Perforce is a really good listener. Between yesterday's presentation on the P4Sandbox beta and today's showing in the popular demo lounge, a slightly more managed approach was imminent. "Based on the customer feedback yesterday, I'm changing one of my answers: The central admin will be able to tell how many sandboxes there are, and how active they are," said Teague. That said, the sandbox doesn't let them do anything more than what they do today in terms of permissions. And it might make things easier by coupling the remote functionality that Git, Mercurial and Bazaar users enjoy with the groundbreaking meta-awareness of streams.

A customer watching the demo was enthused about the ability to work locally but collaborate globally. "This solves the problem that we've had where a developer checks out 90 files, then leaves the company, and you go back later and find all the files are locked," she said.

Indeed, P4Sandbox lets you branch without affecting concurrency or performance. "Our users are distributed across the world. Some of them are stuck behind someone somewhere who just submitted 200,000 files right in the middle of the day," said Teague.

Mirror, Mirror, In the Stream

Creating a local private branch from the depot on the user's machine lets developers try new features without broadcasting them across the company, he explained. "You can work outside code review or branch restrictions. When you get to your final target, you bring it back in line and implement it up." Even better, the mirror stream, a new stream type that handles communication between the local and central servers, merges your 150 changes as a single action, making your explorations less disruptive to the team as a whole.

According to Teague, agile methodologies have made task branching, also called feature branching, widespread. P4Sandbox implements just-in-time branching so that "when you create a branch it's almost instantaneous." Indeed, the 2011.1 p4 sync is ten times faster for small files in lightweight branching, he claimed.

Also, "odds are you don't work with an entire depot but a small chunk of that," he said. The mirror stream [see yesterday's talk introducing streams] mounts the central server as a remote depot. "Not everyone's thrilled with the remote depot idea," Teague acknowledged. Changes to the 2010.2 and 2011.1 server improve performance by not holding open locks on the central server, and not connecting as a remote user; instead, "the sandbox actually connects as you."

Offloading work from the central server will improve its overall performance, while automatic shelving ensures that work is saved when switching among branches, so you can start new tasks easily.

Finally, in the demo lounge Teague showed that the command-line usage of sandbox is "very Git-like. It's more powerful in command line than in the P4V visual client, but that's designed for 80% of our users. But the 20% of our users that want to use more complex structures can do it via command line."