What is Subversion and Source Control?
Source control refers to the management of the changes made to program files and other aspects of software development. Source control also allows a team of people to develop software more efficiently. It allows the team members to work on different aspects of a project at the same time with minimal interference. Source control also normally includes references to revisions of the source code, keeping track of the differences between the versions. It also deals with source tags (normally, tags refer to major milestones in the project), and branches (different versions) of the source code.
Subversion, abbreviated SVN, is a source control program that automates the process of controlling revisions of source code and other such documents. Subversion is freely available from the developing company, Apache. Subversion stores projects in a password-protected repository on-line, allowing access from multiple computers. The repository used for this class is stored on the University's servers; however, some companies (ex. Google) host servers available to the public.
Why Source Control?
Source control allows the development of large scale projects to proceed in a much more efficient manner. Multiple people can be working on a project simultaneously with little or no interference from fellow team members. It also allows for a project-wide undo button. One can revert back to an earlier version if needed. As mentioned before, tags and branches of source code can be made as well. Branches can be useful for different builds of the same program (ex. 32 and 64 bit versions). Tags are equally useful when it comes to keeping track of major milestones of a project (ex. V1.0 or v1.1).
Tips Regarding Source Control and Subversion:
Since the beginning of the semester, the learning curve I've been following is somewhat slow. One of the most major things I wish I didn't learn the hard way pertains to the copying and moving of file directories. Subversion creates a hidden ".svn/" folder in every directory that is in the repository. So, simply copying and pasting folders from place to place can cause some serious pain down the road. The major problem I experienced occurred when I attempted to revert back to our first iteration. I naively deleted the source directory and replaced it with the first iteration. When it came time to commit the changes for the next lab, I committed the changes and they appeared in our tag directory (instead of the original source directory).
Before I realized copying folders was a bad idea, I ran across the problem stating that the folder I was trying to commit changes to wasn't in source control yet (even though it appeared in the repository). I found that the most fool-proof way around this was to checkout a new copy of the project, and submitting the changes from that copy. I believe the problem referred to the fact that the repository had a folder named the same as mine but Subversion didn't recognize it as the same folder. So, replacing the files one-by-one in a freshly checked out copy seems to work the best. I'm sure there is a better way to fix that problem, I would love to know how to since I've run into the problem a few times now. However, I only seem to run into the problem when I'm running close to a deadline, so I haven't had time to figure it out by myself.
My overall experiences with source control and Subversion have been somewhat successful. It was a slow learning curve at first, and it lead to a few hiccups here and there. But, once I was able to get the knack of things, I became rather efficient with Subversion. It's now hard to imagine making a project like this without source control. I have a feeling source control will be a tool I utilize through the rest of my career.