For the project we are developing, my group is using Subversion (svn) as version control. This is a way of accessing a repository shared by my teammate and myself. It allows us to commit changes that are then available to each other on all our machines (lab computers, desktops, and laptops) allowing us to not be tied down to a single location for the master copy. We can divide the project into tasks for each of us to accomplish and commit those changes independently.
Overall, I have had a positive experience with subversion. The ability to access the files freely on a different machine allows us to work flexibly. Luckily, we have not had to revert our project yet. I have tested the functionality and it effectively restores a previous state, which gives me the confidence to commit code knowing that it is not difficult to revert if we end up changing back to a previous structure. I have used the command line interface up to now which, while effective, is not always pleasant to deal with. I am beginning to work with KDESvn which is a graphical interface for computers with KDE. It seems to have all the functionality with a much more intuitive interface, reducing the learning curve of all the command line arguments.
I ran into a frustrating scenario when I was trying to copy to a tags directory. I attempted to do this by copying the trunk folder to a tags folder on my local machine. I now know that this is not the best way of accomplishing this since "svn cp" does a good job of storing only the differences between files. When I went to try to use svn add to mark it for addition to the repository on my next commit, I got a message saying that the folder was already under version control. As a new user to Subversion at the time, I was confused by this as I expected that Subversion would never have seen this folder before and added it. The problem occurred because in copying the folder I also copied that .svn folder, a hidden folder that is used by Subversion to track status. After deleting this from the copied folder I was able to add it as I had expected.
One of the concerns I have with Subversion is the way it handles tags. It requires us to manually copy the entire trunk to a separate folder. When the "svn cp" command is used Subversion stores the difference between files on the server which saves space. However, when these files are checked out you have entire copies of the files. At this time our project is small enough that this is a non-issue but I can imagine a scenario where having a large trunk copied into many tags would cause a project to take up a lot of unnecessary space.
Subversion
No TrackBacks
TrackBack URL: http://blog.lib.umn.edu/cgi-bin/mt-tb.cgi/165158
I've had the same sort of problems with copying files. I figured it out like you did and the problems are easy enough to avoid once you know what's going on. I found it frustrating that svn would say something like "already under version control" and then just stop as if I'm supposed to know what to do about it. Fortunately the solutions to problems like that are easily googleable.
Killain Pukema
SVN is a good tool for people who want to program in a group. I have the same problems when trying to copy a file on local machine without using the "svn cp" command. It really confused my partner and my for a long time. But we now know what wrong with that. We must use the right way to do the copy instead of a "easy" way.
I had no idea that there were any GUIs for SVN. It is cool to read this and find out that I am not doomed to forever lurk in the land of the command shell. Even though the command shell isn't the worst thing ever, it is not very easy to figure out what is going wrong when you have a hiccup. I also didn't know that the .svn folder is what let the SVN server know what is under version control. That is a nice little tidbit of information that will most likely come in handy when trying to manipulate files.
Phillip Egelston
I have experienced a lot of strange things when trying to copy files from trunk/src to the tags as well. It seems like it still has a lot of little bugs, but most of them can be worked around. i.e. I had an issue with getting the contents of a folder added as well. I couldn't figure out for the life of me why this was happening. Then I realized I was having a brain-fart moment and I didn't add the just the folder to the repository yet. Simple things like that can be overlooked easily it seems with subversion.
But subversion seems like a very nice tool for storing files in an organized fashion across multiple machines. I think that is probably one of my favorite features of it. I'm not too much of a fan when it comes to multiple people editing a program at the same time since so many problems can occur, though.
Tom Manion
The problem with subversion is not that it doesn't work, but that it doesn't work the way you think it would. You gave three examples of this:
First, subversion tracks working-copy file status in a hidden directory inside each folder, rather than in a central location, as you would expect.
Second, tags are created by "copying" rather than by simply applying a tag to an existing revision.
Third, some tasks require a checked-out working copy, while others are best performed directly on the repository.
So, your confusion about tags is understandable. In case you're interested, the way tags are supposed to work is you do an svn cp directly on the repo (i.e. using http://... command arguments). There's no reason to do anything to your working copy. As you noted, the tag is stored as a delta to an existing revision, which is space efficient. And you shouldn't ever check out tags; they're supposed to be immutable. So you shouldn't have problems with tags taking up space.
I also ran into that problem with the .svn folder. I managed to figure it out, but I agree, it was definitely confusing.
Also, thank you henc0017, for explaining how tags are supposed to work. I had kind of a hazy idea of how they worked and what they were for, but after reading your explanation I feel like I understand them much better.
Eitan Rogin
Good point about potentially eating up a lot of space when checking out and copying files from larger projects!
For constructive comments I'll add that from experience using acronyms, especially for referencing a previously unmentioned program as with KDESvn above, should generally be avoided when you are writing to an audience whose knowledge of the topic is unknown, as this can lead to confusion and distract from the flow of the blog.