The Test

The siren song, that is svn, has been tantalizing me for the duration of this class. It seems like it'd be great, but then it steers my programming ship directly into a cluster of rocks. Needless to say, my relationship with svn isn't the best, but I think it's just the context in which I'm using it that makes me want to avoid it. 


For those that don't know, svn is short for subversion, and it what is called a version control system. What this does is let many people work on the same project from different computers, potentially at the same time. When you get done with what you're working on, all you have to do is commit the changes you've made, or files you've added, and then everyone else can update the version they have and see and/or edit what you committed. In theory, this sounds great, but what happens when two people are working on the same file and both try to commit it? This is only the first of a few problems that I've encountered with it. More examples will follow. 


As I said earlier, svn is tantalizing. What i mean by this is that it sounds great on paper, and maybe it is great if everyone working on a project that is using it fully understands it, but in practice, for me, it hasn't worked all that well. I concede that I might just think it's stupid because I have done almost all the work on the project in the presence of my partner, and thus have never actually needed to use it. It could also be that I am not the most adept svn user and thus do not understand why I get errors like this:
svn: Commit failed (details follow):

svn: Server sent unexpected return value (405 Method Not Allowed) in response to MKCOL request for '/svn/F11C3081-40/!svn/wrk/5f9b1812-ca24-41bd-95f3-0f07f2abfb3e/project/tags/Iteration2'

I still don't completely know what that one was telling me. 

There is also the problem of conflict resolution. For those who haven't used svn, when more than one person tries to make changes to the same file, you get, what svn calls, a conflict. This can be resolved by merging the two files(although this is something that has to be done manually, as svn does not give you the option when a conflict arises), just using the file you're trying to add, or just using the other person(/people)'s file. If you and the other person making changes were working on different parts of the file, the merge function works great. In the more likely scenario, however, you and your teammate(s) were trying to fix some bug, and both thought you had the solution to it, so who's do you go with then? Of course both people would just use the file they tried to commit, because they both think they are right. This works fine if they are, in fact, right, but if they aren't, people get unhappy when you overwrite the work they've been doing. 

The last problems I'm going to talk about are server problems. I'm not going to go into much detail on these, because I have no idea what causes them or how to resolve them. What I will say, though, is that it is terribly inconvenient when you try to commit something, and it tells you it can't because the server is down. I don't know about everyone else, but when I get error messages regarding servers I pretty much just call it quits, because I have no idea what I can do about it. 

Having said all that, I think svn could be a great tool if everyone working on the project was properly instructed in the workings of svn, and also if everyone had their own separate files to work, as to not cause conflicts. I'm not sure if that's actually a very likely scenario, but it would be the ideal one. So despite my own personal problems with it, I'd recommend it if you're willing to take the time to get to know all it's workings, and are fairly adept with computers. Personally, however, I'm going to tie myself to the mast as to resist the allure of its song.