Subversion, when used correctly, is an extremely useful tool in organizing different versions of files and programs in a single area called a repository. You can think of this repository as cloud storage, it's not specifically located on one single computer but is being hosted somewhere else and you can access it remotely. However the key difference that sets Subversion and all other version control systems (or vcs) apart from simple cloud storage is their ability to keep track of version numbers of every file you update. Each vcs treats this a little differently, some put version numbers on each individual file while others keep track of a global version number, but each one will increment this version number every time a file is updated. This sounds, and actually is, quite helpful when developing a program. Anytime you want to go back to a previous version of a file or program you can have your preferred vcs give you that previous version of that program. Another huge advantage to working with vcs is the ability to have multiple people checkout, or download, a copy of a particular file, modify the file in any way it needs to and then upload it back into the repository. Normally when you think about multiple people uploading the same file one after the other each person would overwrite the previous version and the last one to upload their file gets to keep their changes. It doesn't work that way in vcs. Every time you try to upload a file to your repository it will check to see if the repository copy of the file has been updated since your last upload. If it has, Subversion can show you the changes between the newer repository copy and your modified local copy. This is an invaluable resource when dealing with multiple programmers working on the same file. Everyone's changes can be seen, merged together and a final complete version can be put together for everyone to download again. This all sounds wonderful but isn't as easy as it sounds. The main problem is being able to do all of these things correctly and efficiently. I personally have run into two major problems while using Subversion for our class.
I live far enough away from campus that I do not want to come to school unless I am already there for classes. So on the weekends when I want to work on this class's homework I do not have access to the schools computers. Subversion is very helpful here in the fact that you are able to connect to your repository over the internet, for our class I use a SSH client on my home computer. However, connecting and uploading to your repository doesn't always go as planned. I had this affect me the first time we needed to upload files for blog assignments. We needed to upload two files for that assignment: blog_url.txt and blog_1.pf, sounds easy enough right? Here is what happened, I uploaded blog_url.txt no problem, now I wanted to upload blog_1.pdf and the connection froze. I closed the connection, re-logged in and tried again, same thing, a frozen connection. No matter how many times I tried, it always froze. I tried uploading a blog_1.doc and blog_1.txt both worked just fine of course, only the format that I actually needed to upload would make it freeze. After a long series of frustrating failures I searched for a different SSH client and choose a new one. Guess what happened, this time it finally worked! As a warning to future users of svn or other revision control systems, make sure you have a reliable way to connect to your repository whenever you need to use a remote connection.
The second problem I had involved my partner too. We were trying to update our local workspace to match the group repository. When we would try the 'svn update' command an error message said "Unversioned file of the same name already exists". Being svn beginners we asked our TA, Robert Edge, what is going on and how to fix it. He tried to work his magic but wasn't able to solve the conflict. Everything from explicitly stating the conflict is resolved to deleting the file in question did not work. In the end we actually had to just checkout a whole new, fresh copy of our group repository. For us this wasn't a big problem but what if your repository or the files in it were quite large. This could be potentially a huge problem to try to resolve in a corporation using Subversion.
So, in the end, would I recommend the use of Subversion or other vcs? Yes, because the benefits of version numbers and a single place where all your project files are located that can be accessed remotely outweighs the problems that I have encountered. I have encountered each of these problems only once and, although they were both very frustrating, after they were fixed things went smoothly and everyone was happy again.