These are probably the scenarios you're interested on:

• Continue working on a laptop while disconnected from the office network.
• Connect separate locations together

Continue working while disconnected

Software will always get more complex, so keeping valuable developers is very important to ensure success.

Both agile and disciplined software approaches focus more than ever on productivity and mobility to retain the best talents and giving that talent the tools needed to be successful.

Additionally, there are business trips, on-site collaboration with customers, demos, and so on, situations where having the ability to make the right changes on the right code or document, and ensuring it will be synchronized back, makes a big difference.

Laptops are almost as common as cell phones (and almost as light), with internet everywhere, why should we stay plugged to the offices network to make some changes?

In fact, you shouldn't.

Install a lightweight Plastic SCM server on your laptop, replicate from your central server at the office and start making changes while offline, but having all the features you'd have at the office such us:

• history
• branch explorer
• version trees
• code review
• and of course the ability to check in code whenever you need to

Synch back when you get a network connection or when you get back to the office. Or use Email to send replication packages to the office.

Plastic handles distributed operation with an easy to use graphical user interface, so you continue working the way you're used to, no special commands, no overcomplicated stuff. It just works.

How should you check if a SCM is ok for working disconnected?

• Check its underlying model: is it truly distributed or is just using a proxy? Plastic is truly distributed, but few products out there are, even when they claim they support distributed development.

The only other commercial SCM supporting distributed development is Bitkeeper, while Clearcase supports multi-site development, but it is mastership-based (you can't freely make changes at both sides), and not lightweight at all.

• Is it easy to use? Ok, in case you've not discarded it because it lacks true distribution or is not lightweight enough, can you replicate changes back and forth graphically or do you depend on some arcane admin-only command line interface? You can even create replication packages, files that contain the replication data which you can email, ftp, or copy to a network, to share them with other Plastic servers. Users can work in a totally decentralized mode sharing changes from home using nothing but email and all with a simple point and click interface provided by Plastic!

Making distant developers work together

So you've a group of developers at one location and another group (or groups!) half a world away, and you want them to work together as a team, right?

Well, that's basically what we provide out-of-the-box with Plastic SCM, so we really trust it is the tool you're looking for.

Anyway, let's examine some key points you should consider:

• You can connect a VPN between both sides. Ok, every SCM would work this way (and of course Plastic will do!), but what if the connection goes down or if it's not fast enough? I mean, developers are used to their 1Gbps or 100Mbps connections locally, so anything slower will immediately downgrade their productivity.

• You can set up some sort of proxy based system like most of the SCMs do (including Perforce, Accurev, Team Foundation Server...). Well, it will be better than the VPN, but still the distant groups are not free to make changes as if they were connected locally. Proxies are good, but true replication is better.

• You can rely on some expensive and hard-to-configure multi-site mechanism. Then you can use some sort of mastership-based alternative (products like Clearcase do), but first make sure you hire some good sysadmins to handle the whole process. Buy some extra patience for your developers too, they'll need it

• Or you can go to a truly distributed system. This way your separate groups can work as fast as if they were connected locally (in fact they are!) and exchange modifications as often as they need to. The solution should be simple to set up and administer.

Then, why we think Plastic is worth considering?

• Plastic is fully (and truly) distributed. No proxies, no connection optimizations, just plain distributed support.
• All Plastic SCM servers can replicate changes back and forth with any other Plastic SCM server, so no special steps to perform before synching changes, no weird procedures to follow, no extra steps.
• Plastic SCM drives replication graphically (ok, you can automate whatever you need using the command line too, but the default scenarios are extremely easy), which gives you additional control over the whole process