Vendor branch for core Rails? No thanks, I’ll take a clean copy.

Ruby on Rails Add comments

Tonight I tried to migrate from Rails 1.2.1 to 1.2.3 using the vendor branch methodology I described earlier. Well, after about an hour of playing around and finally running the svn_load_dirs.pl script that they recommend, I had a tagged copy of Rails 1.2.3 Or at least, that’s what the process promised.

Well, I’m sort of the conservative type, especially with configuration management. I ran a diff on the 1.2.3 release from the Ruby on Rails repository versus the 1.2.3 release in my repository. As soon as I saw it start cranking out differences, my heart sank. Maybe I ran diff wrong, maybe I didn’t clean up all the working material from svn, and maybe a thousand other things. Still, the fact that what I had in my repository was not bit-for-bit identical to the official 1.2.3 release sealed the deal for me. Rather than going forward with an unknown, possibly mangled copy of Rails, I just gave up on the vendor branch. I swallowed my pride and just downloaded the official release and put that in the vendor directory of my project, skipping all the tagging and whatnot. The alternative of never knowing whether future bugs were in my code or due to my mangled version of Rails was simply too scary for me.

I still stand by my assertion that vendor branches are great for plugins. In most cases, the plugin code will be small enough that managing the vendor branch updating will be simple. For something as large and complex as the Rails core, however, it is simply too risky of a proposition.

Leave a Reply

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in