Svn

| 6 Comments

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.

6 Comments

I'm curious if in your opinion there are any drawbacks to using a version control system. Or, if you find that there are any particular drawbacks that Subversion has that other version control systems may not. I, for one, am happy that Subversion can mark conflicts when they occur, but I find it difficult to actually decipher the notation and actually choose how to resolve the conflict. Perhaps some system out there has a nice tool for resolving conflicts.

Bobby Homan

I think you well summarized the concept of the “tags, branch, and trunk”. Actually, I was really skeptical on having the copies of our project files because I think it was redundant in that “svn revert” makes us able to go back any previous version we want. However, I realized that it is actually effective when it comes to having different trial versions with different problem solving approaches. I think without saving the different projects files respectively in some way like using the trunk and branch convention, it would be hard to manage all of the trials.

I think you well summarized the concept of the “tags, branch, and trunk”. Actually, I was really skeptical on having the copies of our project files because I think it was redundant in that “svn revert” makes us able to go back any previous version we want. However, I realized that it is actually effective when it comes to having different trial versions with different problem solving approaches. I think without saving the different projects files respectively in some way like using the trunk and branch convention, it would be hard to manage all of the trials.

Your summary about subversion is clear. It will be useful to readers without any idea about version control system. But do you which can be used to get previous revisions of our codes?

Nice summary. You came from the right direction in explaining branches and tags as copies rather than annotation, since that's how svn treats them. This seems wasteful at first, until you explain that svn doesn't actually store real copies. I agree that source control is great, but I just started using git in another project, and I like it better than subversion -- it just feels cleaner and simpler.

Yeah svn is really useful. After reading this, I wonder if professionals for giant corporations use this. From what I've encountered prior to this class, svn was used for projects that were constantly being updated and fed to the public to use.

Scott Gee

Leave a comment

About this Entry

This page contains a single entry by mart2439 published on November 1, 2011 1:19 PM.

Blog 2 was the previous entry in this blog.

Blog 4 is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.