SVN Fix Conflicts Without Merging

The current web site project I’m working on with PHP has a setup where we have our development machines, staging server and production server. We’re developing the code on our local machines, than we push the code to the staging server for testing and if all goes well we’re pushing the changes on the production server. We use SVN as a source version control system. Because the web site has very big traffic and it has many visitors and registered users we have to fix the bugs as fast as we can and deploy the fixes on the production servers as fast as possible. The prompt bugfixing form time to time forces us to make the changes directly on the production. This is done usually by our project manager (who luckily  has good technical background) and although he’s aware that he doesn’t commit the changes to the SVN repository, he’s making changes directly on the production servers and he doesn’t inform us.

Last week I’ve encountered one conflict situation. I was working on a bugfix and the time came to commit the changes to the SVN repo. I did the normal procedure:

$ svn up
$ svn st

I’ve updated the code from the SVN and a saw that there were no conflicts so I committed it back to the repo with my changes included

$ svn ci -m "Bugix: .........."

After committing the changes to the repo, I ssh-ed to the production server to pull the updated files from the repo. I issued:

$ svn st

to check the status of this folder and I saw that there was a file which was changed but not committed to the repo. Unfortunately the changed file was the one that I changed and committed to the repo. So this was obvious conflict which had to be solved.
The normal solution is cases like this is to update the code fix the conflict and and commit the changes back to the repo. The problem was that doing this on the production server means that the web site will work with errors, the code will brake. I mustn’t pull down the site for maintenance so I had to think of another solution. If I tried updating the SVN would’ve marked the differences in the files like:

<<<<<<< filename
    your changes
=======
    code merged from repository
>>>>>>> revision

And the PHP code would’ve not been parsed correctly which means troubles and web site down. I knew I had to do something, to implement the needed changes, commit them to the SVN repo and do an update of the production server code so that it will have the latest code revision, and I had to do all that without pulling down the site

This is what I did. This solution should work with any other script language (any deployment which does not require compiling of the source code).
On the production server I issued:

$ svn status

to see which files have been modified localy, and then

$  svn status --show-updates

to see which files have been changed in the repo. I saw which files have been outdated (which files have newer versions in the repo) and I started looking for the differences and updated the files in the repo one by one. I found the differences with the repo HEAD with:

$ svn diff <filename> -r HEAD

After finding the changes made on the production server, I made all them on my local machine and committed the code back to the SVN repo.

The last operation which had to be done was to checkout the new code on the production server and force to overwrite the locally changed files.

svn checkout --force svn://repo website.dir
svn revert -R website.dir

The first command will check out on top of existing files in website.dir, but not overwrite them. Then the revert will overwrite them.

This is how I fixed the problem with our web site without taking the site down. I hope someone will find this small guide useful. Please write comments if you have suggestions to improve this method or if you have some better solution.