Configuration Management, Part 2

Be nice to your neighbors, now
Rarely in the real world will you be working on a programming assignment by yourself. Usually you'll have to collaborate with several people and the end result is a compilation of everybody's efforts. In part 1 of configuration management, we created and modified two Java stack projects, and we're going to do the same again, this time for a classmate. I was partnered up with Creighton Okada, who created his stack project here. Just as with the last exercise, I checked out the source code, made a slight modification, then committed the changes back to the SVN server.

SVN changelog for stack-okada project

Creighton did an excellent job on his stack project. There were no bugs or errors that Ant could find, and unlike me, he remembered to add in descriptions for all his SVN commits. All I made was a simple Javadoc comment change to his project. Although in this case, Creighton and I were not doing edits at the same time, I can see how being able to do so is a great convenience. When I was working on the CodeRuler project with Tyler, I programmed a certain block of code while he did another. We had a slight clash when we tried to merge the code because I edited some of his loops and function calls to make them more efficient, but he changed his functions so that my calls wouldn't work on his code anymore. In the end we decided to go with my changes, but this problem could've been altogether avoided if we used SVN to keep each other up to date on what the other was coding. If a small issue like this can happen between just two programmers, imagine how much more complex it will get when more people are involved. Even when there's only one developer, SVN can be helpful by keeping revision histories for every file, and it's a cinch to bring a new developer into the project. I know I'll be SVN for my projects in the future since I'm notorious for making big changes to some code that ends up breaking the system, and only then do I realize I forgot to make a backup...

Google Project Hosting, what will they think of next?
Google Project Hosting (GPH) is an interesting beast. The basic premise of the site is to host people's projects and allow anyone to use SVN to manage their projects. There is also a mailing list to automatically e-mail people any time the project is updated, though it would have been nice if GPH itself had a built-in mailer rather than having to create a separate Google Groups mailer and configuring GPH to use it. GPH is very friendly and very open-source; anyone with a Google account can create a project, and anyone can browse and download the source code for any project. They even offer different open-source licenses that your project can fall under. Although not quite the beast as SourceForge is, it offers a simple way for people to use SVN for their projects without having to set up the server themselves. And who knows, putting the project online can even attract new developers, and since it's already on a SVN server and set up, all you need to do is add them as a member into the project and they're good to go!