Copy on Write Repository

In our staging environment, I can deploy many virtual servers in a matter of minutes, for the price of one big machine and no IT involvement. This is accomplished because I share a common OS file system image, across all the OS instances, with a "copy on write" filesystem enabled. Any writes by the OS or a user inside the OS copies the changed file to another read/write filesystem. The original image is never touched as it is read only.

This way I can install whatever OS tools I need once on the shared filesystem. If I mess up a configuration on the dedicated read/write filesystem or just want to start over, I shutdown the virtual server, delete the dedicated image, and start it back up fresh from the shared image.

But this approach isn't practical when you are installing/configuring complex applications or in-house software due to the various dependencies and lifecycle issues like hourly or even quarterly updates and releases.

What you want is essentially a "copy on write" semantic from your revision control system. That is, put the binaries of your applications (NetKernel for example) in the repository, with 'global' configuration options pre-set, 'alongside' your source code and build files.

To deploy or just initialize a new development environment, you checkout the projects that will run on the target development machine, make local configuration changes, and build any applications.

If deploying to a production server, even storing binaries of your in-house applications configured from a staging environment is also a good idea. This way your not debugging a build on a foreign system (even though your build scripts should be resilient enough to work most anywhere).

The problem here is that CVS and Subversion employ optimistic locking. CVS has pessimistic locking ('edit'), but that isn't a solution either.

What you want to have happen is for any changes made locally to be ignored by the repository and thus un-committable.

That is, you don't want to run the risk of them being commited and showing up in other developers environments, but you also want enough house keeping enabled to see what the changes are (how the local version difffers from the repository version).

With CVS and Subversion, you can checkout files and get the housekeeping features but run the risk of an inapropriate commit (which is more likely in your development environment with the additional lack of managed changelists/changesets).

Or you can do a CVS/SVN export , but you loose the housekeeping.

Fortunately Perforce let's you accomplish this. Simply tell the p4 server to allow certain files to be copied locally as read/write, but not in edit mode. This way it knows you have the files and what versions of them, but it won't try and commit or step on your local changes.

So in essence, you get with little effort the benefits of "copy on write". A pristine shared image, with local changes unable to pollute your original.