Double Shot #658 »

Created at: 01.03.2010 13:08, source: A Fresh Cup, tagged: Double Shot canable mongo rails ruby sinatra subversion

New months always hold so much promise.

• Warehouse -"A Web-based subversion browser that doesn't suck."
• Garbage Collection Slides from LA Ruby Conference - A good intro to a tough ruby topic, with pointers to some useful utilities.
• Great CS Program for GIrls Needs Funding - Another good cause that could use some of your hard-earned dollars.
• Using Sinatra to test remote services in Rails - Another testing idea from Elad Meidar.
• Canable: The Flesh Eating Permission System - John Nunemaker's take on authorization. Looks fairly similar to the way I've been handling it recently.
• rails_indexes - I think I mentioned this plugin for finding missing indexes before, but it came in handy this weekend so I'm mentioning it again.
• Support Details - A way to quickly query a user's machine for things like OS, Browser, IP address, and color depth.
• Migrations with Mongo (and MongoMapper) - Otherwise known as "mongrations".
• Lesson from Madlibs Signup Fad: Do Your Own Tests - Amen.

Mephisto: Change from SVN to Git »

Created at: 19.04.2008 18:24, source: poocs.net - Home, tagged: git git mephisto subversion

The fine folks over at ENTP/ActiveReload have released version 0.8 of Mephisto, the Rails application that powers this site. With this new release, they, as everyone these days, have actively shifted the remaining bits and pieces of Mephisto’s development from Subversion to Git. (And its main repository is hosted at Github, where else.)

I hardly remember ever installing Mephisto from a tarball. I always used to track its Subversion trunk for the 3 blogs I run, which made upgrading as easy as svn up && rake db:migrate RAILS_ENV=production most of the time. Well, that was then and this is now. Looking at this recent shift to Git, I wanted to convert my blogs to the new Git repository without excessively messing with whatever I did to my local installation (quickly approaching my 30s, I might not even recall most of what I did). I was pretty certain, however, that I did not have massive local modifications. If I had, this approach might’ve been a little simplistic.

Here’s what I did.

Initializing

Starting out, you need to create a local Git repository within your local blog installation, which is as simple as:

$ cd /your/blog
$ git init
Initialized empty Git repository in .git/

The next step is to setup technoweenie’s master repository on Github as a remote to your local repository and fetch what’s currently in there.

$ git remote add technoweenie git://github.com/technoweenie/mephisto.git
$ git fetch technoweenie
remote: Generating pack...
...

This will fetch both the master branch and all branches technoweenie might’ve created. (This includes, for example, a branch that holds the current 0.8 release, if you don’t dare to ride the edge of Mephisto’s development.)

Merging

At this point we need to merge one of the branches we just fetched into your local (totally empty, for what it’s worth) repository. (I’ve decided to stay on the master branch. If you prefer a release branch, substitute it as appropriate.)

$ git merge technoweenie/master

Since Subversion scatters its .svn folders all over the place, we need to get rid of those. You can either do that manually or with a little find-fu.

$ find . -type d -name '.svn' -exec rm -rf {} \;

Excellent, that’s much better. Now it should be safe to check out the current state of affairs:

$ git status

Running this command will show you the currently untracked files. Those would be all files that existed locally before you started to create your own Git repository and which are non-existent in technoweenie’s repository.

Tracking local modifications

As I mentioned above, I didn’t have a boatload of local modifications. My changes were limited to bit of configuration, a few third party plugins (and the accompanying CSS/Javascript) and my local Mint installation. The additional files and directories that may show up are the cached HTML files that Mephisto sticks in public/.

To actually add your local modifications to your Git repository, simple add and commit them.

$ git add config/mongrel_cluster.yml
$ git commit -m 'Mongrel configuration'

If you’d prefer to rather ignore whatever else sits in your blog directory, add it to .gitignore

$ echo "public/*.html" >> .gitignore
$ echo "public/200*" >> .gitignore
$ echo "public/mint" >> .gitignore
$ git commit -m 'Ignore cache and mint' .gitignore

Cleaning up

I had a few files sitting in my directory that weren’t local modifications but seemed to have been removed from the official repository, too. Those weren’t caught by our merging of the Git branch since we started with zero history. To get rid of those, let’s take a look at git-clean.

$ git clean -n -d
Would remove app/views/admin/article_comments/
Would remove app/views/admin/articles/approve.rjs
Would remove app/views/admin/articles/comments.rhtml
Would remove app/views/admin/articles/destroy_comment.rjs
...

The -n argument prevents git clean from actually doing anything. If you’re confident it wouldn’t do anything harmful, go ahread and remove it. (You do have backups, right? Do you?)

At this point we’re down to regular upgrading business, so you might want to run the migrations and restart your Mongrel cluster. (Or whatever floats your deployment boat.)

$ rake db:migrate RAILS_ENV=production
$ mongrel_rails cluster::restart

Into the future

Now, whenever Mr. Weenie adds an exciting new feature to Mephisto you can grab that via:

$ git fetch technoweenie
$ git merge technoweenie/master

Or if you’d rather prefer to pick a specific commit:

$ git cherry-pick <SHA1>

Further reading

Since this is not a Git guide per-se, I’ll end the article at this point. There is plenty of other content available online to bring you up to speed with Git.

resolving git-svn conflicts »

Created at: 01.03.2008 00:40, source: Rails on the Run - Home, tagged: git git-svn repository scm subversion svn

I've been using git and git-svn for a little while and never had a problem... until today.

On one of my project, we have a SVN repo but since I prefer using Git, I'm using git-svn.

Git-svn has been great, it let me create my own local branches for each new set of features (that's when I don't forget to create a branch) and to commit all the changes back to svn.

The problem today happened after I did a simple git-svn rebase. I had some sort of error and my local repo looked like it got reverted to the head of the svn repo....

error: patch failed: trunk/app/models/view.rb:1
error: trunk/app/models/view.rb: patch does not apply
[blah blah]
sing index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...

I hadn't committed to SVN for 24 hours and had a lot of work that was just checked in locally... You can imagine the panic. Rob started digging in the .git repo to finally find the hash representing the latest delta before the rebase. With the help of the #caboose guys, I did a simple

git reset --hard hash-name

Which restore my repo to the pre SVN commit state. Awesome... however I still had issues to commit my stuff. After a little while I as able to commit again, worked a bit more and tried to commit again.... same error :(

But this time I noticed I could simply do

git rebase --abort

to restore the original branch.an

But I still couldn't commit properly... until I discovered that I just needed to fix the conflicts manually using

git-mergetool

git-mergetool uses whichever merge tool available: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff filemerge

I fixed my conflicts in no time, then did a

git rebase --continue

and finally

git-svn dcommit

Looking back, I wish I knew how to properly deal with conflicts when using git-svn, I wasted a bit of my precious time ;) hopefully this post will help you.

p.s: here is an interesting use of Sake to handle git-svn