I'm not really sure what I think of using source control as a tool for programming. Having worked a bit with source control software I've become undecided if I really like it or not. Source control is nice to actually have the ability to go back to an earlier version after you've managed to completely gum up the working version. It can also be a pain when two people are working on the same files and haven't committed their versions for a while. Perhaps it's just subversion that can cause headaches. I have not used any other source control software so I am unfamiliar with the workings of them and am really unable to draw a complete conclusion on all source control software.
One of my earliest experiences with subversion was when I had not properly submitted a lab assignment that was due. I thought I had turned it in, but turns out I hadn't. Having moved on to a later lab I somehow completely erased what I had done from the previous lab ensuring that I would have to redo that lab. It was some combination of subversion updates and reverts that had lost what I had done with no way to recover it (on a side note the second time I did the lab, it decided it didn't want to compile properly and I still managed to get a zero, go me).
I find that I'm not using subversion exactly how it should be used. Uploading to subversion should have some kind of non-broken source code committed although it seems my partner and I kind of use it in a way of "we'll get back to that" instead of actually just keeping a local copy and then committing it when it's not broken. This is probably going to lead to complications later in programming, especially if we keep adding more files. We might get to a point where we never know what files are working properly and which ones aren't.
I feel I am being a bit negative on subversion which I find odd because I actually do like using it. I think it will be a strong tool when I am fully comfortable with using it in which it was intended. I like that I can branch out into different directions when writing a program and then be able to go back to an earlier version if it turns out I'm some kind of idiot. I also like that I am able to keep a log of what I have done to the program step by step for each version. Granted comments in a program do that, but they don't provide a timeline like subversion does. Another good feature that I just haven't gotten familiar with yet is merging. It's nice to have multiple people work on different parts of the same files and be able to merge them together. The only thing I'm finding difficult is when we both happen to change the same lines and have conflicts but I think that is just something I have to do on a regular basis to just get comfortable with it.
Subversion - it 's ruthless and mean and I kind of like it!
No TrackBacks
TrackBack URL: http://blog.lib.umn.edu/cgi-bin/mt-tb.cgi/164915
I've been having the same difficulties with svn. Hopefully they go away as we become more familiar with it. I like your sarcastic writing style. It makes the blog fun to read.
Mark Edwards
First, I feel sorry about your accident. As you mentioned the reason why you think Subversion is mean is because you are not comfortable with it yet. If you commit and update frequently and appropriately no such problems would occur in the future. In my opinion, subversion is a very effective tool when used properly. Just imagine how difficult it would be to manage a project without version control system with 10 people working in a group.
First, I feel sorry about your accident. As you mentioned the reason why you think Subversion is mean is because you are not comfortable with it yet. If you commit and update frequently and appropriately no such problems would occur in the future. In my opinion, subversion is a very effective tool when used properly. Just imagine how difficult it would be to manage a project without version control system with 10 people working in a group.
Sun Kim
Yes, I think whether SVN is effective depends on whether users are familiar with SVN commands. It just the matter of time to get used to SVN commands. I think SVN commands are quite intuitive, so with a little testing like commanding SVN add, commit, update, copy, remove, log, status, and revert on some dummy projects even for two hour, users might quickly understand what’s going on there.
I agree that SVN has both advantages and disadvantages. For most of the times, my partner and I are doing the project together, which is a kind of waste to use verion control, since it allows people doing it individually. Thank you for sharing your experience wih us, and I learned from your accident.
Good luck.
I agree that SVN has both advantages and disadvantages. For most of the times, my partner and I are doing the project together, which is a kind of waste to use verion control, since it allows people doing it individually. Thank you for sharing your experience wih us, and I learned from your accident.
Good luck.
Lingfeng Ye
I agree that svn can be hard to use at first If you are not used to using it as your version control client. Having your whole project stored in a file directory with your only means of control being the svn terminal commands can be quite daunting. SVN, like most other open source/gnu style projects has a steeper learning curve than most proprietary software. However, svn is relatively simple and widely used, giving it an inherent advantage over similar software.
Nate Martin
In respect to your problem with the "we'll get back to you later code" commits I've found that doing that is fine, so long as you clearly indicate what is working and what isn't in your commit message. For example, If I had a working method (call it Dummy) but I wanted to change the way it worked, or make it more robust so it could be utilized in more ways. What I would do if I couldn't get it working before I had to commit I would clearly indicate so in the message. I would put something like "BUG: Dummy isn't working properly after trying these changes". This way with more commits more often you will be less likely to have too many conflicts when working with a group but if they get it and it doesn't run then they can do a "svn log" command to see what was committed and why it doesn't work.
Andrew Torgerson