How to synchronize Subversion and a remote server (via FTP)?

Question

We are having difficulty maintaining the synchronization of Subversion and FTP. Sometimes we forget to commit changes and just push them to the web server, we have .svn folders scattered throughout the web server, some things exist in one place and do not exist in another, etc.

I want to take the time to fix it today. What is the solution? Is there a way SVN can be linked to our web server so that we can commit both the repository and the web server via FTP? Should we ask our web host for any other system that better syncs with the SVN repository? How do we ensure repository and web server synchronization? How to delete .svn folders?

As the name says, how can we synchronize our SVN repository and our web server?

Answer 1

What I do on my server is checking the code on the server.

Therefore, instead of using ftp to move things to the server, I just connected to it and started svn up . Thus, you get several advantages, including the ability to roll back in case of a faulty code.

I also recommend using the db migration system (assuming you are using a database). This will allow you to easily roll back db schema changes to make sure your code will continue to work if rolled back.

Combining them with a tool like Fabric or Capistrano will give you a very reliable and powerful deployment system.

Note about DVCS:

Some people mentioned using distributed vcs . Some of the most popular examples of them are: git and mercurial (there are others).

Both of them have a different usage pattern than svn, but this does not apply to this issue directly. The biggest gain you can have is that if you make tags for every click on a live server, then the cost is minimal compared to the traditional svn template.

If you would like to expire with any of these GitHub and BitBucket both offer free repository hosting for git and mercurial respectively.

Saying that I am a huge proponent of using dvcs, and my personal preferences are mercurial .

Answer 2

You don’t want to commit changes to a real web server without any form of testing, could you?

Short answer: by performing a new check (preferably on a central server) and copying only the bits necessary to run the application.

I would recommend setting up continuous integration , where your build server is responsible for getting the latest sources from the Subversion repository, building and preparing deployment packages for different environments (testing / installation) and, possibly, an FTP connection to the product box when you are happy with the changes deployed in a test or intermediate environment.

This is the only reliable way to ensure that changes must be made (no problem, I know, but apparently don't know your scenario), otherwise they just won't end up in deployment. It ensures compliance with the effective release management process, and not forget that you can add all sorts of other wonderful automation things to your build server, such as unit testing and functional testing.

Answer 3

Springloops does exactly what you need. Give it a try. It is SVN combined with FTP. You work on your local working copy, then commit the changes to the repository, and then through Springloops deploy the selected revision to any server (Staging or Production) via FTP.

Answer 4

I would suggest that before implementing below, you are using a test environment in which you can directly FTP, and then click "live", commit this version of the files and enable this task.

From tigris :

This is done all the time and is easily achieved by adding a post-commit script hook to your repository. Read about hook scripts in chapter 5 of the book. The basic idea is to make the "live site" just a normal working copy, and then use your post-commit hook script to run the 'svn update'.

In practice, there are several things to watch out for. The server program executing the commit (svnserve or apache) is the same program that will run the post-commit script hook. This means that this program must have the appropriate permissions to update the working copy. In other words, the working copy must belong to the same user that svnserve or apache works as - or at least the working copy must have the appropriate permissions.

If the server needs to update a working copy that it does not own (for example, user joe ~ / public_html / area), one method creates a binary program + s to start the update, since Unix will not allow scripts + s to run. Compile the tiny C program:

 #include <stddef.h> #include <stdlib.h> #include <unistd.h> int main(void) { execl("/usr/local/bin/svn", "svn", "update", "/home/joe/public_html/", (const char *) NULL); return(EXIT_FAILURE); } 

... and then chmod + s with binary and make sure it belongs to user joe. Then, in hook-post-commit, add a line to run the binary.

If you are having trouble connecting the hook, see "Why are my repository handlers not working?"

Also, you probably want to prevent apache from exporting .svn / directories in a live working copy. Add this to your httpd.conf:

 # Disallow browsing of Subversion working copy administrative dirs. <DirectoryMatch "^/.*/\.svn/"> Order deny,allow Deny from all </DirectoryMatch> 

Answer 5

Try http://svn2ftp.com - none of the main project management functions, you just can’t configure SVN repositories that will automatically sync with any amount of S / FTP for each commit.

Answer 6

Install a post-commit hook that updates FTP and uses SVN exclusively for changes. Thus, when the changes are completed, your web server will be updated.

The web server is assumed to be an intermediate server. See comments for more details.

Answer 7

The best way I've found to do this is to ensure that no uncommitted logs to the server — this is a loophole that you must fix first.

Then configure local verification of the parts of your repository that you want to synchronize and use rsync to push data to the server (FTP is really not that useful in this context). rsync allows files and directories to be excluded, so use this tool to ensure that .svn directories are not synchronized.

Answer 8

I was about to offer Springlops when I scroll down and saw Chris offer. I have been using SpringLoops for the past few months and absolutely love it.

You can configure FTP data for intermediate and intermediate servers for each repository. You can then publish these servers via FTP by specifying the version number for deployment.

Something I really like about this is that I can see in which version each server is located through the deployment page in Springloops. And with everything that is deployed through Springlops, you know that for sure.

I really hunted for a solution that is something more than just an SVN repository .. something with a built-in ticket, wiki and timekeeping. I like Bitbucket alot, but it does not have the Springlops FTP deployment feature, which unfortunately excludes this for me. Until I stick with Springloops, until another service offers an FTP deployment.

Why FTP deployment is so important to me, I hear some people muttering under their breath. I will be happy to tell you: I am getting divorced on different servers. Some of them are dedicated mailboxes, some cloud-based virtual machines, and some shared hosting. I do not want to support a separate deployment methodology for each of them, so FTP is the only deployment method for everyone. Springloops sits very well between my source code and my servers. That's why:)

Answer 9

This site shows how to configure Subversion to do exactly what you are looking for. http://www.itforeveryone.co.uk/svn2web.html

Answer 10

This looks like a problem specifically designed for a distributed version control system.