Subversion Under Control

There are a few things that will be tackled and reflected upon for this post. Version control for my open source project, bug selection, project building, and reflection upon Chapter 4 of Teaching Open Source.

VERSION CONTROL

First, version control. Instead of just using Subversion, like my last team project, we will be handling the usage of subversion and git, putting me under the assumption that we can use whichever we prefer - for me this will easily be git. I had a blog post in the past where I compared and contrasted subversion and git, but I will touch up on some of the highlights now as a refresher. A subversion reference can be found here and a git reference similar to the one I used whenever I learned git can be found here. Git and subversion have the same goal: version control, but that have different feels and these different aesthetics really manifest themselves in which gui you use - granted this is circumvented by just using the command line.

The terminology in git is a lot easier for me to grasp since it is the first version control system to which I became accustomed. In subversion, a "commit" is the final step in having your changes exposed to everyone else on your project. In git, a "commit" is the penultimate step with a "push" being what exposes your changes to your partners. This allows commits to be sent out in batches or changes be made at the last second. It really is not a big difference, just more of a preference.

BUG SELECTION
Most of the bugs in Galaxy are pretty abstract and have multiple people working on them. We, as a team, wanted to find a bug that was non-critical so that we would not end up working on a bug that gets fixed quickly by someone else because they have a head start on us or because it is critical to their personal work. So after much perusal, we stumbled upon this bug on Galaxy's Trello page. Essentially, we just need a way for comments to be allowed for this specific tool and this can even be abstracted for use with other tools in Galaxy. When conducting this bug fix we will also be contributing documentation for how to use our fix, as it will have a user input component as that is required for Galaxy.

PROJECT BUILDING
Everyone in my group has been able to build Galaxy, as their build documentation is top-notch. A simple install of Mercurial and a command within Mercurial builds Galaxy and grabs all dependencies. The only outside dependency that has to be installed is Python and that is already bundled in to a lot of Linux builds by default, so that really is not even an outside dependency. Mercurial is its own version control system, but I think we will be just using subversion or git to manage our version control since we, as a group, are more familiar with that and we do not want to have to jump over hurdles just to get our files in order.

TEACHING OPEN SOURCE -> CHAPTER 4
The introduction is really a PSA as to why software developers should use version control. You do not want to have dozens of versions of a file - it's so hard to compare which one is the best one and make sure you didn't forget someone's revisions from an older version. Version control is great (and I'd suggest using a form of version control even for writing collaborative papers - dropbox usually is good for this as conflicts can be settled easily). Additionally, with version control, you can back up and check previous versions so you can essentially undo someone's edits if it turns out that their ideas turned out to be just crummy.

The chapter then jumps into the basics of subversion, explaining how to make changes (e.g. svn add, svn delete, svn copy, svn move), conduct updates (i.e. svn update), commit changes (i.e. svn commit), etc.

Music listened to while blogging: Krizz Kaliko & Tech N9ne