Questions[version-control](server)

Imagine you're going to manage a number of servers with a number of different services that's used by a number of people. Now say you want to reconfigure or replace some software on one of those servers. Obviously you don't want to work on servers that are in production.

If this was a code change, as a developer, I would make the change on my local development machine, test it locally and commit the change to a version control system. The changes could then be deployed in a staging environment, tested further and finally deployed in a production environment. It would also be easy for me to roll back, if necessary.

Generally, or specifically, how do you achieve this in system administration?

(The first thing that comes to mind is to use virtual machines and put virtual machine images in version control, but I'm sure there is a lot of literature and clever solutions I'm not presently aware of.)

I am trying to come up with a way to deploy ASP.NET code with as little site disturbance as possible. One thought was to set up the site to be served from an NTFS junction c:\www\example.com where

c:\www\example.com -> c:\www\example.com_r1234

Then, when new code is deployed, it gets copied to c:\www\site.com_r1235 and the junction retargeted to

c:\www\example.com -> c:\www\example.com_r1235

So my question is what affect this might have on current requests in IIS? What other drawbacks might this have from the point of view of IIS's reaction to the change (if any)? Will this be as seamless for the end user of the site as I hope?

(I've considered changing the site's web root through the command line, but I really don't like the idea of reconfiguring IIS because of any unnecessary app domain or app pool churn that might happen, but I don't know a lot about what happens when the configured physical path of a site is changed while under load)

To be clear, my only concern here is the experience of my end users. My aim is to avoid disturbances for them, not convenience for me.

I want to make a central config file repository so that I can have the changes to any config under revision control (Mercurial). This will include some GNU/Linux boxes (which will use etckeeper), the network equipment's config files, printer's config files and last but not least, windows configs.

I know you can import some configurations like ISA's and DHCPs as text/xml files and even shared folders as a registry key, but for stuff like GPOs and AD, IIS, MSSql and others, are there ways to get the configs as flat files? Basically, can you have something somewhat equivalent to etckeeper under windows? Something like some powershell based commands or the like?

Also, can ACLs and other file permissions be preserved under version control (hg)?

BTW, I've already read

• What solutions exist to allow the use of revision control for server configuration files?
• What tool do you recommend to track changes on a Linux/Unix server

to no avail.

Are there any version control systems out there that are particularly good (or bad) at dealing with large files? Nothing too crazy, but from several hundred megabytes to a gigabyte, let's say.

We currently have subversion in place, but there are some mutterings about it not being ideal for this purpose. I'm not a developer myself, and I don't know how objective they are being, so I thought I'd do a quick community survey for extra info.

I'm interested in the behaviour or suitability of these VCS solutions from a systems point of view as well as the user point of view.

TIA.

I would like to setup a central Mecurial repository on a Windows 2008 server which only allows both push and pull access to certain users. This is to allow developers working remotely to push/pull changes through the central repository while working remotely.