Blog Closed

This blog has moved to Github. This page will not be updated and is not open for comments. Please go to the new site for updated content.

Wednesday, August 27, 2008

Version Control Woes

I'm hardly an expert on version control, but I've been using it now pretty regularly and I think I've picked it up pretty quickly. I use SVN every day, between Parrot and some of my other projects. Even if it's just a quick update or merging in the day's changes to a local branch. I use Wikis too, which I realize now to be a very large and elaborate version control system with a very specialized interface.

At work we use version control too, although it takes the form of a large and disorderly mismash of various filesharing and group collaboration tools. Microsoft Groove is one of the major tools that we use, and I've written about it before. Groove is interesting because it allows quick intra-office communications, it allows distributed file sharing, and a few other easy-to-manage tools and forms. We use Groove for a lot of things around the office, including keeping track of the calendar and making purchase requisitions. I'm still very interested that we keep using Groove though, it's a program that I don't find to be particularly good at anything, other then mashing together several functionalities that otherwise would be handled separately.

The way we use Groove to organize files at work is terrible, literally terrible. If you don't already know where something is, you will never find it. Files are versioned manually, so when I make an update to a file I have to rename it. So we have folders with "file_version1" and "file_version2", etc. Our software is stored in a subfolder of the software documentation folder. The software documentation folder also contains documentation for all other aspects of our project including hardware, installation, application notes, etc. These are just a few examples but trust me, it's bad. Also, the choice as to whether to use email or groove to send somebody a message is usally pretty arbitrary, and the fact that I am expecting communications through both vectors regularly means I need to pay attention to them both. Every day I wish there was some kind of plugin to interface Groove and Outlook to help demultiplex my messages into a single inbox. Somehow, I doubt it's ever going to happen like that.

We have a file sharing server in the office that we can use to store large files that are not suitable for use in Groove. There are some problems with the default permissions on this, however. We can add and modify files and folders, but we cannot delete them remotely. I also don't know where the server is physically located (nobody else seems to know either) so I can't manage it locally either. Without being able to delete things it's quickly become cluttered and obnoxious. However, it's still a very fast way to move things between computers in the office, especially those computers without groove. All the flash drives in our office seem to have been infected with some obnoxious virus too, making this file share all the more important. Virus writers, as I've said before, are the scum of the earth.

We also use regular source control, we have two source control programs that are in use. One is used by the engineers, poorly, and one is used by the website people. I say the engineers are using the source control poorly because they are: Groove is used to store current revisions of our software (manually named by version number, as I mentioned above), while our source control is only used to store current production versions. This is because the projection and manufacturing devision take the current version of the software out of source control when they commission a new unit, so we can't have anything in there that isn't "perfect".

It's amazing to me that so many people, especially so many decision-making engineers are so inept when it comes to using tools like these. I know this kind of stuff isn't taught well in school, but it only takes a little bit of experience using them to learn what best practices (or at least better practices) should be. I realize people are probably paralyzed with the intertia of the status quo, but if I had the opportunity I would rip it all out in a heartbeat and start over.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.