I didn’t really learn how to use subversion specifically, or really version control in general, until I quit using subversion and started using git.

The evolution started with VSS. Essentially it was a code backup. We did the occasionally file rollback, but that was it. Write code and periodically check it in, comment-less of course. I had a brief affair with SourceGear Vault. It was a much improved replacement for VSS. Though it fixed a lot of the bugs and other issues in VSS, but as I move more away from the Microsoft world, it became less useful.

Enter subversion.

What a breath of fresh air. Edit-merge-commit. Open source. Quicker. Concurrent development. Nice. Then I started learning about branches and tags. Wow, those could be useful. “Could” being the important word. Using branches and merging in SVN is certainly possible, but trivial. So I used them occasionally, but never with confidence or as any core part of my development process.

Then the cool kids started chanting “git, git, git”.

So I checked out what all the fuss was about like any good hopelessly addicted to new technology freak would do. Git was hard and a bit scary. Yeah, the whole “clone, add, commit” thing was fine, but start talking about rebasing and my head hurt. Git 101 tutorials will only take you so far and the rest you have to learn in the trenches.

I’m a few months out now and I wouldn’t go back. Oh wait. I have to. I still have a slew of projects in SVN. As I go back to those projects, I’m using SVN in ways I never would have previously.

Yesterday I had a bug to fix in a production app on Rails 2.0.1. It has been running without issue for over a year. So I go into my dev machine to make a quick fix and realize that I started to upgrade the app to 2.1.0 about 6 months ago. I have 6 or so commits but never deployed any of the changes. I can’t deploy them because they were never finished. mmmm.

Before git, I’d probably just make the changes on the server and back the code into the trunk. Gong. Being much more comfortable with branching and merging from working with git, I simply created a stable-1.0 branch off of the revision that was last deployed, applied the changes there. A quick update to my deploy.rb file pull from the branch rather than trunk and thencap deploy. Done.

My point of this ramble is that choosing to work with new (different) technologies matures you as a developer. And the things you learn will give you a new, and generally better, perspective even when you work within your wheelhouse.

At work I have had numerous projects (mostly in Ruby) that involve creating and/or reading these fixed-width text files. Occasionally, I have the luxury of a CSV file and can use FasterCSV to take care of business. To date, I haven’t had a single project that used XML.

Given the need, I decided to create an open source project. I had to work on it primarily on my own time, as our work environment is not what you would call “open source friendly”. So, slither was born.

Definitions

Here’s a simple example. Assume you have the following file format:

Here’s a sample file (cars.txt).

200606011999BMW                 325                Smith      45500
200506011993Honda               Accord             Wood        7500
200601022006Lexus               350                Johnson    25365

Given this file, we would first need to create a slither definition.

Slither.define :cars do |d|
  d.section, :body do |body|
    # The trap is not very useful here since there is only one section
    body.trap { |line| line =~ /^\d{8}/ }
    body.column :date, 8
    body.column :year, 4
    body.column :make, 20, :align => :left
    body.column :model, 20, :align => :left
    body.column :name, 10, :align => :left
    body.column :price, 6
  end
end

Parsing

From there we could parse the above file like this:

# Arguments are the file path and the definition name
parsed_data = Slither.parse("cars.txt", :cars).inspect

It should return a hash with nested arrays keyed by section.

result = {
  :body => [
    { :date => "20060601", 
      :year => "1999", 
      :make => "BWW", 
      :model => "325", 
      :name => "Smith", 
      :price => "45500" },
    ...
  ]
}

Generating

To generate a file, simply do the opposite. Create a properly formatted hash and call generate:

# Generates the file as a string
puts Slither.generate(:cars, my_car_hash)

# Writes the file
Slither.write("cars.txt", :cars, my_car_hash)

Just the Beginning

There are many more things that Slither can do:

• headers and footers
• templated sections
• typecasting
• formatting
• validation (not quite there yet)

So go ahead and install the gem or fork the Github project if you’re interested in hacking.

# Run the following if you haven"t already:
gem sources -a http://gems.github.com
# Install the gem(s):
sudo gem install ryanwood-slither

Here’s an example from the wiki. You simply install the gem and run wheneverize in your root dir. Then add the following to your config/schedule.rb file:

set :path, "/var/www/apps/my_app" 

every 10.minutes do
  runner "MyModel.some_process" 
  rake "my:rake:task"  
  command "/usr/bin/my_great_command" 
end

will yield…

0,10,20,30,40,50 * * * * /var/www/apps/my_app/script/runner -e production "MyModel.some_process" 

0,10,20,30,40,50 * * * * cd /var/www/apps/my_app && RAILS_ENV=production /usr/bin/env rake my:rake:task

0,10,20,30,40,50 * * * * /usr/bin/my_great_command

For more on setup and deployment, see the README. RubyInside has a nice review as well.

This will show the commit differences between my-dev-branch and master.

$ git checkout my-dev-branch
$ git cherry -v master
+ cf9221200cb9574e3cc92fa72570f9813b86af24 Moved configuration out of lib folder
+ 32c456574cb58a2a8c9b354b5eca56b6f28bab82 Fixed some bugs

I guess It pays to start digging deeper into the underlying git commands.

Command Line

One of the toughest areas, is getting comfortable with the command line. Most of the subversion users I know rarely, if ever, use the svn command line utility. The simply stick with a nice GUI client. When learning git I would argue that you need to learn the command line. If you don’t understand what is going on under the covers, you can really end up in a ditch. The documentation is pretty good, but unless you are a command line junkie, it will take some time to move your version control mindset over.

And make sure you keep your install current. There has been lots of good stuff added in recent days.

It Takes Thought

The power of git comes at the price of understanding. Version control becomes more than a simple “right-click and commit every once in a while” endeavor. Git allows you to craft your commits so your repository is clean and tells a story of how your app developed. Using rebase you can rewrite, combine, remove and edit commits. It crazy and dangerous and comes with significant responsibility, but the price is worth it. Check this out.

Confidence

The biggest hurdle for me was gaining confidence that I could be productive and wasn’t going to destroy my applications inadvertently. The resources available are getting better and better and better. However, confidence only comes with experience. It doesn’t matter how many books you read on dating, at some point, you have to walk up to that personal and ask them out. Confidence requires action. Luckily, git won’t throw a drink in your face or laugh at you.

If you’re on a steady diet of svn, compare and give git a try. You know you want to.

• a rapper
• an artist
• a film maker
• a model
• a wide receiver
• a left wing
• a lawyer
• a doctor
• a guitarist
• a consultant
• a distillery
• a church

My parents should be proud!

“The Ruby Toolbox gives Ruby developers a categorized overview of 100 or so different libraries ranked on how commonly used they are. It’s not perfect as it only pays attention to projects hosted on Github and the ranking system is based on the number of watchers and forks they have, but it’s enough to give you a basic overview of the activity within a certain area.”

It’s a really nice resource to look at when trying to pick a plugin for a particular task when there are just too many to choose from. RubyForge has stats as well.

• authlogic: an excellent authentication framework for Ruby and Rails. It’s quickly replacing restful_authentication as the standard.
• settingslogic: a small app config gem similar to app_config.
• trollop: a great command line parser for ruby apps. Beats the tar out of optparse.
• factory_girl: a solid replacement for fixtures
• sinatra: a lightweight HTTP server. Very nice.
• logging: a replacements for the aging, outdated log4r project.