October 2011 Archives

My experience of SVN


I never used source control before this class. In Lab01, when I got started on it, I thought it was just a repository and my partner and I could put our work into the same place, and then the TA could check our work from there. During Lab01, we were learning the basic command of svn(Subversion), a popular source version control system like CVS. I found that svn was very complicated and that I did not see any advantage when using it. It takes us lots of time to build a workspace and checkout. However, while deeply studying, I found I am totally wrong, since svn is actually pretty helpful and easy to use.

First of all, a source version control system is not only a simple repository, but a place that can store all the various revisions of the ideas that we commit. Therefore, it provides a project-wide undo button that we can easily roll back. For example, in Lab05, we erroneously replaced our source code "readInput.cpp" file by an automatically generated one. We were so worried at first about it, but it was svn that we were using. Consequently, we typed "svn revert readInput.cpp" in the command line to revert the local changes to the file.

I think the most beneficial feature of Subversion for us is that it allows us to edit files, same or different, in different places at the same time. For example, after checking out the files from the repository to my laptop, I can work without the CSE lab machines. So can my partner. Therefore, we do not need to schedule and find a place to work together all the time. We usually just split our workload and then work on our own time. Using update can help us get the latest files from the repository while using commit can help us submit our changes. Also, any conflict of editing the same files is easy to handle since version control provides a good conflict resolution system. For instance, sometimes I add small changes to our programs, just testing the functionality in my workspace, but do not commit the changes. Before my next update, Keng may have already edited the same files. It doesn't matter, because when I updating, svn will change the name of every conflict file, and every conflict part in the programs will be marked observably.

Our project consists of lots of iteration. The same files may have different revisions. Tags help us keep track of these files which are from different iteration. For example, we first work in the mainstream directory. After we finish the iteration, we copy the files to a new directory in the tags, like the "Iteration1", "Iteration2" and "Lab_06" directories that we already have. If bugs arose in one tag, we will just work in the specific tag as if we were working in the mainstream.

In general, Subversion is a really helpful source control system that we cannot work without it.

Benefits and challenges when working in team


I am really happy to work with my partner, Keng. We can learn from each other, and consequently, it made us more efficient to accomplish the iteration 1.

3081 is a writing course. I am not good at writing. Although English is also a second language for Keng, his English is pretty good. Therefore, he can help me correct my writing in the project. Furthermore, when we run into a question, the TA usually does not know what I am trying to ask. But he can describe it properly, so we can ask the TA easily or Google it ourselves. On the other hand, Keng is familiar with the command line. He knows many useful commands. For example, if I want to open Emacs using command line, I would type "Emacs". After that, I need to open another terminal since my original process switch to run Emacs. Then Keng taught me that I could type "Emacs &", then it would create a daemon process which runs Emacs, and I could still use the terminal. It is pretty convenient.

We think thoroughly about the puzzles in the project before we met. For example, I did not know how to make a string or a line comment in regular expression. So I bore this question in my mind, and discussed it with Keng when we met. Then we Googled it and each kept trying on our own. I used to write many codes before this class so that I could implement our ideas quickly. We finally finished it through our efforts. Because we knew the specific questions before we began to work, so it would be more efficient to figure them out in group together. Therefore, we can write down our specific questions of the future iteration before we work together. This ensures the same benefits occur next time.

Although there are a lot of benefits to work together, challenges sometimes arise. First of all, we need to find time that we are both available to meet. But this semester is crazy. Homework and projects are published one by one. I do not have any free time. I think Keng is also busy this semester, so we do not have very much time to meet. Thus, I tried to do some of the work by myself. I finished all of the required regular expressions before we met. Although this was a time-consuming task, it was pretty simple to do it since I just needed to copy them one by one, and then modify them a little bit. Therefore, it was easy for us to do the remaining parts when we worked together. If we do not have very much time available for the following meeting, we can keep in touch with each other through email, and come up with an outline of the project. Using this process, we will just need to consider the tiny details when we work together. As I mentioned before, my English is not very good. When we work together, sometimes I do not understand what Keng means, and sometimes he also does not know what I am trying to say. Still, he is patient enough to talk with or listen to me. Thus, English has not been a big challenge until now. But I should note that I need to practice my English frequently. It is not only important for this project in 3081, but is also one of my key priorities while studying in the U.S.

There is another challenge that would not have occurred in a single-programmer environment. Because I am a bit of a control freak, I always want to change my partner's code to my style. It is a bad habit of working with others. If I have already hurt Keng, I am really sorry about that. Maybe this problem has not yet occurred, but I used to do it last semester. Keng is a pretty nice guy, and I should keep in mind that this project is both of ours, so I should respect his work. I can organize our codes together, but cannot change his code. I hope this is not a challenge for us in the future.

About this Archive

This page is an archive of entries from October 2011 listed from newest to oldest.

September 2011 is the previous archive.

November 2011 is the next archive.

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


Powered by Movable Type 4.31-en