We had a similar system at a client site once. We handled it like this: - Install Apache on local machine- Copy entire file share to local machine- Make changes and test- If test works, rename local copy to reflect date- Copy changed files from local shadow to file share- Upload changes from file share to production server Unfortunately, there was a race condition here, where we might be testing changes to file XYZ at the same time the client's own developers were working on XYZ. So they might alter the file between us making the copy and copying the changes to the file share. Eventually this broke something, and the client complained. We pointed out that what he really needed was a source control server. He insisted this would be too complex. We pointed out that there was no way to prevent this; between the time I opened the file and the time I saved it, anyone could have done anything to the file, and the same problem would happen. His "solution" was that you should never change any files - just make new ones. We despaired of ever explaining just how big a WTF this was, and simply agreed to the new policy... which we never followed, and when he called us on the carpet for it (not because something bad happened, but because he noticed we were changing files) we pointedly remarked that we were in the process of trying to close out his contract and remove him from our client roster. The policy disappeared immediately. Instead, a new policy was instituted for the client developers: to never save files while our contractors were on site. We discovered this when one of the developers was haunting our team and asking when we were going home... he wanted to correct a typo on a form, but under this policy, he couldn't do it until we left for the day. WTF begets WTF.