Blog 3 Subversion and Source Control

    Source control is a way for software developers to maintain and manage code. It is a very useful tool when working on a large project with a group of people. Using source control allows team members to work on the same code files from different locations and times and keeps all files in sync. Another very useful feature of source control is the ability to roll back or revert to an earlier version. We've run into situations before in lab where we messed up a file tinkering around with our makefile. It changed all our code in a file into jibberish. But luckily for us, we were able to revert that file to a previous version via svn revert ourFile.
    For our WTF Project we have been using svn as our revisioning control system. It is terminal based and, for our purposes, simple and powerful enough. Using svn allows us to work on a local directory and upload it to a repository when we commit it. Uploading it to a repository means that any team members assigned to the repository can get the latest version to their local directory by updating. This means that any team member can work on the files from anywhere, at anytime and commit the changes to the repository so that other team members can update their local directory from anywhere and anytime. Of course this committing and updating requires good communication across the team otherwise there will be conflicts when committing and updating.
    When all team members are able to communicate effectively, running into conflicts will almost never occur. So most of the time, using svn to commit and update is very easy. But when there are conflicts, perhaps using a source control with a gui would be easier. In svn when you run into conflicts, it can be quite hard to figure it out. Sometimes it is just a simple merge of code and reviewing it and then resolving the conflict. And sometimes it has to do with hidden svn files and directory structures that can cause a lot of confusion and trouble. But when it comes to a situation like that and I can't seem to solve it, I just backup the files I've changed to a different directory and delete the whole local directory and check it out. After the checkout, I just copy the code from the backups to the local files and commit.
    So for anyone planning to use svn, the main commands you need to know are: checkout, update and commit. Everything else can be Google'd when it arises. Use checkout for a fresh local directory copy of the repository. Use update if you already have a local directory to get the latest version from the repository if any, I always use this before I start coding away. And finally use commit when you've made changes to files, so that it uploads the changes to the repository. Also don't forget to use the -m for committing files, it allows the person committing the changes to comment what he/she is updating/changing. This is very useful when the group is planning to go back to a certain revision number.


You have some very good arguments here about the benefits of using SVN. But, I'm sorry to say that I got lost reading your blog entry. Though I understand what you have said, one of the topics you mentioned in the first paragraph were not discussed. In your first paragraph, you mention that SVN is a helpful tool that allows people to access the same code remotely and that SVN will keep that files in sync. You also mention that SVN allows you to revert to a previous version of a file. In your second paragraph you discuss how SVN is a helpful tool by committing changes and using update. However, in your next paragraph there is no mention about reverting a file. I read a discussion on conflicts, which I agree is an important point but what happened to revert? The last paragraph talks about commands and provides advice on using using SVN and the last sentence talks about returning to revision but still no discussion on using revert. Maybe you meant to talk about conflicts and not revert?
-Cindy Khan

You pointed out some really good points. From my experience, I like using the TortoiseSVN which makes it easier on the user. It helps show what is actually going on. It also isn't terminal based, which makes it easier to manage.

Come to think of it, source control with a GUI would probably be quite a bit easier. Even though the way conflicts are currently displayed is... functional, it still leaves a little to be desired in terms of readability, at least for new users.

Michael Nun

Leave a comment

About this Entry

This page contains a single entry by lorxx033 published on November 3, 2011 11:14 AM.

Blog 2 Working in Groups was the previous entry in this blog.

Blog 4 Testing is the next entry in this blog.

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