Blog 3 - Subversion and Source Control

| 4 Comments | No TrackBacks

        This time, we talk about Subversion and Source Control.  Before start to talk these two tools, I guess I can introduce what is version control system and source control system first.  First of all, version control system, as the name suggests, it can help programmer to control the version of program.  Imaging that one day you finish some coding, it work very well.  However, next day, when you want to add something new functions into your code, the code become buggy and buggy, finally, you just can't go back to begin.  You also forget to make some backup or tags, so you starting coding the first part again, and feel painful.  Though it can be avoid by some good habits, such as diligent backup your code, or make tag when you finish a part of work.  But once you forget, something bad will happened.  Using version control system, you can easy go back to previous version, and you can also compare two version are different in which part.  Though coding still painful, but using version control can let you feel much better.  Secondly, sometimes we need to cooperate with people, and one case we can imaging is, if two or more people try to work on same code at the same time, what will happen?  First, we need to upload the code when we finish, but different content with same file name, so we may over write other people's code.  So we can image that finally only the last upload people's code will stay.  How to avoid this problem?  Source control system can solve this problem.  This system will tell user that someone already committed the newer version, and asking user want to overwrite or compare with two versions.  And after compare two different versions, user can edit each part that code is different.  Then commit again and overwrite.  It sound like source control system is really powerful, but it has some annoying part.  For example, last time I just committed a code and then I still working on the same code, but as the same time, my partner saw that code and found that the format he doesn't like, so he move all the curly parens, and mix some if-else into switch case.  Through the code still work the same, but when I want to commit, I will see almost the whole code change.  It sound really fun, but if it happen on you, it is not fun.  So using the source control system, if you want to make some big change, try to let your partner know.

 

        Subversion, I think this tool just have both version control and source control, because once you committed, it will be a new version.  And it also can let user compare where the different between two versions is.  Though I use this system only half semester, I still have some experience on using subversion.  To call Subversion, we need to use "#svn"and uses some function follow it.  <%svn checkout [URL]> or <%svn ct [URL]> is the first time you need to use, it can make your computer linked with the group space.  That makes sense after doing this, your computer become one of the working space.  You will see a .svn folder in your space, that's why Subversion can automatic update or commit to correct site.  <%svn update> or <%svn up>is a most frequently used command, if something updated, it will show "U ppp.cpp" this kind of message, because you never know when you partner will committed their code, so do this command every time.  <%svn add [file/dir]>this can add files or directories to workspace, but they will be uploaded only after you committed.  <%svn status> or <%svn st>can show you what file is not in your workspace, such as "? asd.cpp".  And show what files you edited this time, such as "M zxc.cpp".  <%svn commit -m "message for this version"> this is also one of the most important commands in the Subversion.  It can upload all your change to workspace.  And there are some useful commands like use <%svn mv oldname newname> to rename, <%svn revert [file/directory]> to undo all change in this time to last version, but this command only can work before you committed.  <%svn copy>can let you make your tags or branches, <%svn merge> can mix two version's codes.  <%svn info>will show up information about these versions, <%svn log>will let you know the history of version. Finally, there are some status will show up during you using some commands.  "?" is for file which not in workspace, "A" is for files that this time you add, "C" means that file has been change, so cannot be merge, you may need to edit first, "D" means this file will delete from your workspace, "M" is for files you modified this time, and "U" means this file is been updated to new version.

 

        Subversion let me feeling good during Iteration1 and Iteration2 working with my partner.  But I'm still not very good at creating tag or when should make branch.  Practice makes perfect, I will keep trying these command and one day I'll good at using Subversion.

No TrackBacks

TrackBack URL: http://blog.lib.umn.edu/cgi-bin/mt-tb.cgi/164564

4 Comments

I like the way you explained subversion because a new user could read this and understand the fundamentals in both using and seeing the results of svn usage. Based off what you said I take it you never had issues using svn. If you do you might have to use the --force command to get svn working again. In the extreme case you might have to go to an administrator, a TA or the teacher, to get svn running again. My partner and I had that issue, as a group and individually, and had to go to office hours to correct it. Be aware that the svn server could be down for whatever reason so don't try to work around that in subversion or you will get many errors once it is back up and running again.

Manual backups are definitely more of a pain than subversion. I'd never remember to do it before a major change and if I wanted to go back or even just take a look at what I was doing before I was stuck. I had a similar problem while doing formatting changes and rearranging of our code and you're right that it is a bigger problem than it seems. Of course a little coordination with my partner would have prevented that so I should be able to avoid that particular headache in the future.

Garrett Johnson

The most common issue I've had with subversion is people trying to reformat or "fix" code that doesn't need fixing, especially when you are likely working on that portion of the file in your working repository. It's interesting to see that other people have had the same problem. I've found that it is most effective to clearly allocate the work beforehand so that no one is working on the same source code at the same time.

Because most of the labs use work from previous steps it becomes difficult to divide the work thus making subversion inefficient because we end up modifying each other's code.

Leave a comment

About this Entry

This page contains a single entry by Cheng, Chung-Yuan (Arthur) published on November 2, 2011 12:00 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.