Setting up svn in retrospect on a production system

Question

I've got a production environment in place that was deployed using a tarball before the subversion trunk was made available.

Now that it's up and running I still want to have an svn available so that I can immediately commit any changes made. Since the svn project has been created nothing has changed.

Is this possible without disrupting the production platform, e.g. is it safe to use svn co --force https:svn.hostname.com without accidentally killing something?

Answer 1

DO NOT create your working copy in production. Checkouts should be made to a separate development environment, and deployments to production should happen only when desired (usually via svn export of a validated revision).

Answer 2

I would generally steer away from operating SCMs on my production boxes.

My preferred solution is to run an audited automatic build/test environment in the development arena, and generate traceable audited build artifacts (e.g. .jar files) to transfer to production.

I'm not going to stuff up production boxes with long running builds or runaway tests. I can build as and when I want without disrupting the production server responsiveness. My artifacts are built consistently in an isolated build sandbox. Because the builds are automated there's little chance of two builds being done differently (I believe that any human intervention is going to introduction some potential uncertainty).