I’ve been learning git lately and it seems much easier to use than subversion for branching and merging, but I still have yet to become adept at looking at a file history. It seems to be the way that a lot of projects are moving, especially for rails and open source projects; besides, all the kids are doing it, so I figured I would follow the trend. In addition to using it pretty simply for small projects, I’m moving a project from subversion to git, which turn out to be a little bumpy, so I thought I would share.

I started with these awesomely simple instructions to cleanly migrate your subversion repository with the addition of a handy script to automatically create an svn.authors file.

This all seemed to go well, until we tried to run the code and learned that svn-git failed to fetch a directory! svn-git really ought to warn you somehow that it doesn’t support fetching externals. This I learned by noticing that the svn log had no checkins of those files and then saw when I did a clean svn checkout that it was fetching externals for the vendor/plugins directory. Of course that makes a lot of sense, but I didn’t set up the svn so I didn’t know. Then I spent some time wandering through the wilderness of blogs and mailing lists learning about svn externals and git submodules, and I found some interesting clues:

After all of that, I stepped back and thought about what I actually needed for this project. We’re currently at 2.0.2 and planning to upgrade to the the latest, and it turns out that all of the plugins that we’re currently tracking on subversion have moved their latest versions to git. So, I decided to just pull in the vendor/plugins directory verbatim, detaching the external reference, and move to git submodules as we upgrade. What I really wanted to do, but didn’t see how to, was to reference the plugin code as an http URL and keep as a submodule, so that I would have a handy reference to source location and revision.

$mkdir project-tmp
$cd project-tmp/
$git-svn init svn://myserver/project/trunk
$git config svn.authorsfile ../svn-users.txt
$git-svn fetch
Checked out HEAD:
  svn://myserver/project/trunk r999

$cd vendor
$svn co svn://whatever.com/myproject/trunk/vendor/plugins
$cd plugins
$rm -rf .svn  
$git add .

$cd ..
$git clone project-tmp project
$rm -rf project-tmp

So, I’ve been working to migrate my ultrasaurus weblog from Movable Type to WordPress (this one will come later). Since all the links were changing anyhow, I decided to move from ugly numbered permalinks to pretty links based on the title of the post. I only had a few hundred posts, but enough so I didn’t want to be doing it by hand. Since I’m learning Ruby and infatuated with it at the moment, I wrote a Ruby script to generate the .htaccess directives.

In case this would be helpful to anyone else, here’s the code:

[sourcecode language=’ruby’]
require ‘date’
require ‘find’

Find.find(‘./archives/’) do |fname|
# puts fname
date_string = “”
title = “”
next if File.directory?(fname)
File.open(fname, “r”) do |f|
f.each_line do |line|
if m = line.match(“(


)”) then
date_string = m.captures[1]
elsif m = line.match(“(

)(.*)(</h3)") then
title = m.captures[1].downcase

# for some reason my mt archives include some old drafts with no titles
next if title == ""

oldfilename = File.basename(fname)

# 1) remove chars that I think wordpress removes
# 2) change spaces to dashes
# 3) handle this case to avoid —
# Emmy Award for Outstanding Lead Actress – Miniseries or Movie
# also avoid — which I saw in my data, but not sure why it was there
# 4) remove trailing dash if there is one
# Thank you ruby-talk http://www.ruby-forum.com/topic/167299
title = title.gsub(/[(,?!'":.+=/)]/, '').gsub(' ', '-').gsub('–','-').gsub(/-$/, '')

# get the new path to the entry, like "/2003/03/brand-new-weblog/"
date = Date.parse(date_string)
newpath = sprintf("%d/%02d/%s/", date.year.to_s, date.month.to_s, title);

# we want something like this:
# redirect 301 /old/old.htm http://www.you.com/new.htm

output = "redirect 301 /sarahblog/archives/" + oldfilename + " https://www.ultrasaurus.com/sarahblog/" + newpath
puts output

end # loop thru files in directory

In pretty much every blog tutorial generate scaffold plays a central role; however, the rails guides don’t say much about scaffolding. I wasn’t sure where to go next in my development, as I asked in my last post: “Adding attributes and other models: do I scaffold again or just write code?”

I’ve spent some time reading about scaffolding on the Rails lists, and have saved some enlightening posts from various folks. Most of the interesting discussion took place just a few months after the introduction of Rails 2 when the generated scaffold code apparently underwent significant changes to become more REST-like and the dynamic scaffold command was removed from the core of Rails (but is still available as a plugin).

What was dynamic scaffolding?

> 1) In a controller class to bind controller to its respective model as in
> class ContactController < ApplicationController
> scaffold contact # contact here is the name of the model called
> contact
> end

This style of scaffolding has been removed from Rails 2.0. It used to be referred to as dynamic scaffolding, but it didn’t really help people learn about Rails or give them a way to modify the generated interface, so we killed it.
— nice response by DHH to a new Rails developer

Many of the Rails folks are clearly not fans of scaffolding at all and some argue that it is at best good marketing and at worst causes people to become rigid in their use of Rails. Rails is “opinionated,” but it is also designed to be flexible.

What is Scaffolding?

Scaffolds != Rails

They’re a starting point, and as such just give you something to start with. Scaffolds aren’t meant to be your whole application, so the code is treated just like code that’s written independent of them: If your object model changes, then you need to change your views and controller logic to match. — Jeremy McAnally

Just look at the generator as a secretary who can type all the “vanilla” code for you, then edit the migration to add the specifics… I need longtext for my notes fields, but the scaffold just uses text… so I always edit the migrations after they’re generated.

But listing your fields on the generate command does get those fields auto-populated into the views, letting the “secretary” do more of your typing for you.– Ar Chron

it does what the name implies (“scaffold”, remember?), which is A Good Thing. In other news, the “preferred way of working” is still, after all those years, to actually writing code while knowing wtf is going on. — Johannes Holzer

What is Bad about Scaffolding

…scaffolding really is such an insignificant part of Rails that its flaws should have no bearing on your decision of whether or not to use Rails. Rails isn’t a visual toolkit, it’s a serious development framework. You just have to make it over two humps in the learning curve: the Rails API hump and then later the Dynamic Ruby hump and you’ll be golden. — dasil003

my biggest problem with the new scaffolding is that it reinforces the notion that a “resource” is a controller/model stack. That, in turn, means that it discourages recognition of those cases where a resource might involve something other than a one-to-one
correspondence between a controller and a model.

In REST, there’s nothing about the concept of “resource” that implies database persistence, or persistence at all for that matter. Of course, Rails is a database-centered technology, not an all-purpose embodiment of every nuance of “resource”. Still, I think the
scaffolding presents too monogamous a picture of controller/model relations, if I may put it that way. The result is that people worry that if they do something in one controller that involves two models, they’ve done something “unRESTful”. That’s a red herring. — David A. Black

I was confused about it; Roy Fielding (I think it was) explained it like this: a resource is like your P. O. Box; you know where it is; it never changes; and the postal workers know where it is, it never changes. But, what you’ll find in there? Whatever the postal workers
think is appropriate. The analogy is imperfect, because you can’t do content negotiation at your P.O.Box. Imagine if you could say, “I only want first-class mail, please, no bulk mailings, English versions if available” and then the analogy is pretty good, I think.

My very first ReST Web Service was written in Python, and serves geographic conversions for Northern Ohio. (GeoGeeks: available at http://uber.engineer.co.summit.oh.us/ws/spc3401/ ) There’s no real reason to expect anyone to request any given resource more than once, so it’s not a database, it’s just a calculation. It’s not very browser oriented. It also doesn’t do CRUD — just “R.” If I’d learned Rails 2.0 scaffolding first, I might have had even more “unlearning” to do
before I got straightened around.

Rails 2.0 is “ReSTish” and that’s good, but it’s still browserfied. The adaptation of ReST to the browser by Rails is very, very clever, but perhaps a little distracting. Interested people might look at http://pragdave.pragprog.com/pragdave/2007/03/the_radar_archi.html for an example of why providing a ReST Web Service shouldn’t be conflated (mentally) with manipulating it via the browser. — Ron Phillips

> However, as far as I could tell, Rails now makes it really hard to

> deviate from RESTful approach, and that forces me, the newbie, to

> stick to it.

This just described why I think scaffolding is bad. It indirectly forces newcomers to do things a specific way. If you use the scaffolding, you start building controllers based off the code there. If you learned to create a controller and views without the scaffolding, you’d be more free to do things as you see fit.– Branko

Scaffold should not Substitute for Documentation

Railes substitues proper “getting started” documentation for scaffolded
code generation which makes it really tough on newcomers. People who’ve
been doing Rails as long as I have don’t really care because we don’t use scaffolding. However, I work with newbies all the time and it’s much easier to start them on Rails 1.x and move to Rails 2.0 and REST later. The original scaffold generator was very good for explaining how controllers work with models and views. link_to used a hash and not a named route. Named routes are cool, but they are confusing to a newbie. Same with

The only upshot for Rails 2.0 scaffolding is that it’s much more production-ready. — Brian Hogan

In training people in Rails, I definitely do not start with REST and resources. map.resources is essentially a macro that creates a bunch of named routes for you — so if you don’t know what a named route is, you can only do it in a black-box and parrot-like way. Learning named routes doesn’t make much sense until you understand routes, and routes don’t make sense until you know the basics of the request cycle… and so forth. So I would never introduce someone to Rails by telling them to write map.resources in routes.rb and trying to proceed from there. — David A. Black

Scaffold == Marketing

I think part of the problem is that “scaffolding” should not be part of any Rails developer’s vocabulary. Scaffolding is too limiting and “opinionated” to be useful in 99% of real-world applications. Not to mention all the RESTful issues that David A. Black has already
mentioned. You can’t really be RESTful AND be scaffolding.

In my humble opinion, “scaffolding” is the marketing tool to convince people to check Rails out. I know it worked on me a few years back. But, for most, it will quickly become forgotten. —Fred

Scaffold has its Place

Philosophically, the name scaffold was chosen early on to suggest a temporary structure upon which you can lean as you start building but one which you intend to take down as the main structure begins to sustain itself. In that regard the 2.x implementation is more sound philosophically: the scaffold exists in the early stages of development in a way that will always go away over time. — AndyV