October 12, 2011

Distributed Development and P4Sandbox

Version Control

Distributed development can mean a lot of things depending on the context. I think of it as two related but distinct areas. I'd like to dive into those areas and talk a bit about how P4Sandbox will help both cases.

First, there's the idea of supporting a user base that is geographically distributed. Companies big and small are collaborating with partners or offices around the world. Just here at Perforce, we have offices in the US, Canada, the UK, and Australia. In this context, Perforce has a lot to offer, including proxies, brokers, replicas, and now P4Sandbox. Proxies, brokers, and replicas are tools deployed as part of a coherent architecture to offload file transfer work or read-only operations from the main server. They also help with general scalability, supporting large user bases or heavy automation. With these tools, more data is stored closer to the end user, making most operations faster. (Replica servers actually make read-only operations a purely local affair.)

P4Sandbox, as a tool for the end user, fits a different niche, but still helps in this case. If you're a user at a remote site, everything you do in P4Sandbox is local, except the occasional push to and pull from the main server. P4Sandbox has the potential to drastically reduce the communication between a remote office and the main server, giving the users a much improved user experience. And because P4Sandbox doesn't have any administrative overhead, it can be deployed on an as-needed basis.

The other context for distributed development is really a case where there's a very slow or non-existent pipe to the main server. That can certainly happen if you have an office overseas, but it can also impact people working from home over a slow VPN, or those (like me) who spend a lot of time hacking on airplanes. (There's wi-fi almost everywhere, but it's usually slow unreliable wi-fi that doesn't play nice with my VPN client.) At Perforce we have several people scattered around the country, so this is a pain point that we truly understand.

P4Sandbox, of course, will make life a lot better for these types of users. If I start up a P4Sandbox and seed it with the slice of the main server that I normally work with, I'll be a fully independent hacker, able to work with all of my Perforce tools. I just need to push/pull when I'm connected to the main network again. That really brings a feeling of independence: before P4Sandbox, I'd hesitate about diving too deep into some scripts unless I could check in often and save my work.

P4Sandbox has a lot more to offer than just helping with distributed or offline work, and I'll be exploring some of the other productivity gains in future articles. In particular, that feeling of independence I get from having P4Sandbox is due just as much to being able to make private branches for my potentially throw-away work. But I'm getting ahead of myself...

I think P4Sandbox has the potential to reshape the way that you work with Perforce, even if you work in the main office on a high speed network all the time. P4Sandbox is a really exciting tool, so stay tuned for more news and a beta release this fall.