October 2011 Archives

blog 3


As using the subversion for nearly two months, I developed some basic knowledge source control. Source control system consists of some repositories and a number of clients. There are many functions that can be implemented using source control system; for example, this system enforces its own user authentication which allows the source control system to maintain updates to each file, specifically, taping the command diffs, for differences. Storing only the differences, the source control system can keep track of all changes. When you want to see a complete copy of your file, the system performs a merge of the differences, actually, these differences are kept in separate files until you merge your updates, and then you can perform a commit action. We use this approach very often in order that my partner and I are in the step. Thus, this approach allows me and my partner to work in parallel, simultaneously writing code for multiple shared projects, without the danger of an individual's code changes overwriting another's. So source control systems can protect you from code conflicts and loss of early sources. In addition, you can store related file in your source control system project. When you pull a project, or check out the project file; the newer version of the project file overwrites the older version without merging. You might share your project file among all the developers on your team, and when you check a project file into a source control system repository, the source control system overwrites older versions of the file with the newer one without attempting to merge changes.
However, there are still disadvantages to use subversion. I remember when we were doing the iteration 1; we have to move the file in "lab" directory to a new directory "project". I just copied the whole document to the new directory, then I am not able to turn in my work since there are many hidden svn file in the document, I have to delete them one by one. It took me about two hours to turn in that homework, it is nearly the same time that I wrote the code. After that, when turn in the iteration 2, I have to make sure just copy the file to a new directory, thus get rid of the hidden svn files.
In conclusion, source control has provided numbers of useful functions that can allows multiple developers to work on the same code base in a controlled manner; keeps a record of the changes made over time. In addition, allows you to support multiple releases of your software.

Blog 2


Before going to college, I didn't have much experience working in team. Since all my work is asked to be done individually in high school. My concept of working together is blurring. Actually, I have to say I have no idea how to work in team on one project. However, after two years in college, I have learned a lot from working in teams. The benefits of working in teams seem obvious, but the challenges are still inevitable.
I will share some experience in working together with my partner in programming. Two years ago, I had my first computer science course 1901, and it was also my first time to work in pairs with programming. My partner has a lot programming experience, although we are supposed to work together, actually, I didn't get a lot chances to program. But at that time, I am not really care about if I can do programming or not, I just wanted to finish the lab, get the problems done. After the lab, I spend a lot of time reading the code wrote by my partner. However, it is very difficult for me to understand. I want to ask him what's going on, but for most of time, I didn't know how to describe my question. In addition, because of we are in two different levels, I can't understand his explanations. I think my situation is different from most of students, but it is the truth. I have different partners in 1902 and 2021, but I have to say, I didn't make much contribution in team working. Most of the time, I tried to understand the code written by my partner and learned more or less. As for the course 3081, I started to learn more from working in teams, my partner and I discussed the problem together and tried to understand it together. We keep almost the same pace and we understand each other. I think we work better together because we communicate better. We know we are on the same track and it is much more efficient. Since there are still many labs and projects in front of us, it will be a good chance for us to work together and learn more from working in teams. In opinion, I think we should keep communication a lot, expressing everyone's thoughts. Whenever someone get a question, say it directly, don't be shy and shameful. If you keep silence and stay confused, you will find the problem getting more and more confusing as your work continues.

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.