Can Subversion replace FTP?

Question

We currently use Subversion to coordinate the development of our website between two developers. Between us we may work on a bunch of files, check in our changes and upload to the production server at set intervals using an FTP client.

I feel like I'm missing something obvious here, but do we really need FTP? Lets say we make a bunch of changes on our repository is there a way we can just round up all the files that have changed from a certain date up until now and then push those live to a separate repository that holds the production site? At the moment we are using the SVN log to see what files have changed and then we are manually selecting and uploading in the FTP Client.

The repository we work on is already on the production server just not in the folder that IIS is referencing to run the site.

Any ideas would be much appreciated!

EDIT 16th Jan ------------------------------

How about an FTP plugin for Subversion so that I can go into the "Log Messages" area identify the files that have changed in a given period, select them and FTP to production? Does such a tool exist?

BTW: Many useful comments here, thank you all for your contribution.

Answer 1

I found your hero : Bazaar is a distributed version control system that enables easy collaborative development. One of Bazaar's strengths is its adaptibility to different work flows. You choose: work centralized, distributed or anything in between his strength is that it is able to read/write remote repositories using FTP or SFTP (no need to a client program on the other end)

I think svn2web can do it also!

Answer 2

Yes. The answer to your question is Yes. Subversion can replace FTP.

Answer 3

FTP is a great way to transfer files. It is what it was made to do. SCM is made to manage source code. You need some deploy management and it should be automated if possible. If it were me, I would write a script to get the changed files from svn and deploy them over SFTP or FTPS automatically. A script that does the deploy the same way every time is ideal.

You might also look into rsync. It is fast, sends diffs, and is secure.

In my experience, when you add large files such as VM images or videos to source control, it slows down development especially when you create a branch or pull the repo to a new box.

Another contributor suggested Dropbox for both SCM and Deploy Management. I frown on Dropbox for source code. It doesn't provide the merging functionality you will be used to coming from SVN. I have used Dropbox in production for cheap automated back-up. I had WHM/Cpanel dropping the backups in the Dropbox folder. Be sure to turn off network sync as most Data Centers don't like the UDP packets traveling the internal network.

Answer 4

If you were using FTP to push back and forth programming changes, you are better off with a version control system like Subversion. Subversion not only handles the latest code issue, but handles cases where both of you are updating the same file at the same time. Plus, it gives you a version history, so you can see what changed over time and why.

FTP is useful when you are sharing library objects (a .jar file, a .dll, a .so, etc.) between develoeprs. There is no relevant development history that you could pull out of the file, and you aren't going to directly modify these files. Plus, these files age very quickly, become obsolete, and take up a lot of room in your repository.

Be careful with FTP. It is not a secure protocol Someone listening can glean the passwords. Use SCP or SFTP instead. These are related to the sshd daemon, so if you have the ability to use ssh, you can probably setup scp and sftp.

Instead of using FTP, another possibility is to use Dropbox or an equivalent program for sharing these files. Dropbox automatically will update the files between all of your developers, so they don't have to remember whether they fetched the latest code or not. Plus, there is some version control aspects. You can see some version history, and even fetch an older version of the file. Dropbox is secure, and all transmissions are encrypted. Files on the Dropbox server are even stored encrypted (although Dropbox itself does keep the keys to decrypt these files due to the ability to share files between users).

Answer 5

First of all: you must understand difference and never mix Source Control Management and Deploy Management - they are different tasks and jobs, performed by different tools.

While SCMs can (somehow) be used as deploy tools, it isn't common practice due to SCM limitations in this (deploy) area.

Back to your question.

If you RepoServer and ProdServer are different host, you can use any underlying transport, which they support. FTP (if you have choice) isn't best not only from security POV, but also from possible flexibility - common task of uploading some tree to target isn't easy and transparent job for pure FTP, FTP sessions are poorly automated. Resume - if you can use another transport, you can at least try to adopt your deployment process for another transport.

Answer 6

FTP or SCP still comes handy when you want to send files back and forth to your server that do not necessarily need to go through the version control. Subversion is a version control tool and should not be used as a conduit of transfer for files that are not versioned. So my answer is that you should keep both.