Yo 'sup everyone. In case you hadn't realized this is my blog about versions control and more specifically Subversion. Subversion (svn) is a type of version control software that we are using to create a sample compiler. Version control software basically stores the past versions of files so that they can be viewed at a later date, even if the files have been overwritten. This is very useful, as when working on a large project programmers tend to make changes to their code, and sometimes these changes don't turn out to be very good. This is obviously useful because you can go back and grab a file from a time when it worked, before you screwed it all up by trying to add some feature or improve the run-time, or whatever you were trying to do. Subversion has a repository where all of the files are stored. One nice feature of subversion (and other version control software) is that you can make directories in the repository. This is rather useful as you can split up your files into different folders, such as the different projects, or different versions. For example you might want to save a version that you have working. The version is already in the repository, but you might not want to remember the version number, or the date when this version was saved. So you create a directory that holds this working copy. These working versions are called tags by convention. So we (my partner and I) created a tags folder that contains the finished working versions of our code for the different iterations. This is really nice because sometime in the future, potentially a very long time someone may want to look at the code and maybe try to improve on it. With these tags they can just look in the tags folder, and everything that's in there will work. You don't have to hunt down the correct version. Everything not stored in the tags we store in what we call the trunk, again by convention. We follow convention because we want other people to be able to understand what we did, and if we become used to this, we will be able to understand what other people have done. With svn the repository can be set up so that multiple people can access it. This is awesome because a group of people can be working on a project and everything that they do can be stored in one spot, and constantly updated. This way the programmers don't have to hunt down the other people to try to figure out what they changed and get the other versions from them. Which leads to another feature of Subversion. Whenever you try to update your copy of the files to what is in the repository, Subversion checks if there are any changes. If your copy, and the copy in the repository don't match, Subversion will try to merge the two versions if the differences don't interfere with each other. If changes have been made to the same parts of the code, then Subversion brings up an error message, and outlines the parts that are conflicting. Both the merge and the conflict features are useful because it makes it really easy to see what has changed. All in all Subversion is great.
TrackBack URL: http://blog.lib.umn.edu/cgi-bin/mt-tb.cgi/164966