How to keep Subversion and a remote server (via FTP) in sync?

Question

We are having a hard time keeping Subversion and FTP in-sync. Sometimes we forget to commit changes and just push them to the web server, we have .svn folders scattered throughout our web server, some things exist one place and don't exist in the other, etc.

I want to take the time to fix this, today. What is the solution? Is there a way that SVN can be linked to our web server, so that we can commit to both the repository and to the web server via FTP? Should we ask our web host for some other system that would better sync with the SVN repository? How do we enforce that the repository and the web server are both in sync? How do we remove the .svn folders?

Just as the title says, how can we keep our SVN repository and our web server in sync?

Answer 1

You wouldn't want to commit changes to a live web server without any form of testing, would you?

Short answer: by performing a fresh checkout (preferably on a central server) and copying only the bits required to run the app.

I would recommend setting up continous integration, where your build server is responsible for retrieving the latest sources from the Subversion repository, performing a build and preparing the deployment packages for various environments (test/staging) and potentially FTP'ing it up to the production box once you're happy with the deployed changes in your test or staging environment.

That's the only solid way of ensuring that changes WILL have to be committed (no-brainer I know, but seems to be uncertain in your scenario) or otherwise they simply will not end up in the deployment. It enforces the process of good release management, not to forget you can add all sorts of other wonderful automation things to your build server like unit testing and functional testing.

Answer 2

What I do on my server is have it be a checkout of the code on the server.

So instead of using ftp to push things to the server, I just log on to it and run an svn up. By doing this manually this way you gain several benefits, including the ability to roll back in the event of buggy code.

I'd also recommend using a db migration system (assuming you're using a database). That'll allow you to easily roll back db schema changes to make sure that your code will continue to work in the event of a rollback.

Combining these with a tool similar to Fabric or Capistrano, would give you a very robust and powerful deployment system.

Note about DVCS:

Some people here have mentioned using a distributed vcs. Some of the most popular examples of these are git and mercurial (there are several others).

Both of these have a different usage pattern than svn, but that doesn't really apply to this question directly. The biggest gain you could have there is that if you do tags for each push to the live server the cost of doing so is miniscule compared to the traditional tagging pattern for svn.

If you wished to expirement with either of those GitHub and BitBucket both offer free repository hosting for git and mercurial respectively.

That being said I am I huge proponent of using a dvcs and my personal preference is mercurial.