Open Sourcery

I was busy merging work back and forth between topic branches today and by accident miss-merged a 700-line spec. Everything else was fine (or so I hope) except this one file. I couldn’t use git revert, since that would mean I’ll have to redo all the merges I made.

So in panic I googled and read several man pages, coming to the following conclusion that worked quite well:

1. Find the offending commit with git log or git log -p, not the revision number prior to the catastrophic change.
2. View the file at that point in time with git show SHA-ID:path/to/file
3. Replace current copy with git show SHA-ID:path/to/file > path/to/file
4. Verify the damage has been undone with git diff
5. Commit
6. Breathe

Git is a double edged sword, it is extremely powerful and useful, but can be a real pain in the behind. I love git, and will not easily be convinced to move to something else.

It came down on me like a ton of bricks when I deployed the audit updates to our production PowerDNS on Rails setup, hoptoad isn’t installed and any errors would just be gone and forgotten.

The solution is pretty simple, if you use git. This quicky will show you how I’m currently doing it.

Multiple remote repos

All our projects have their origin on our own servers, and then either have “github” or “rubyforge” remotes for public changes. This works very well, especially allowing the team here to work on ideas for a couple of days and deploy to a staging/production server for review. Only once we’re happy do we push the code back to the public.

Basic idea is that our public master branches should always be deployable. Nothing sucks more than getting a OSS project and it doesn’t work out the box…

Enter the deploy branch

We all have a tracked “deploy” branch, which exist only in our private repos, not on Github/RubyForge. This deployment branch was used just for our capistrano recipes. As of this week I decided to through hoptoad in the mix as well, which great reward already.

The principle is so simple, hopefully the flow below explains the process.

Master is either your code, or a clone of someone else’s, and the deploy branch contains your modifications for your environment. In our case its capistrano recipes and hoptoad, but could include New Relic’s RPM as well (or anything else).

The deploy branch should have only additions, and no other changes are made to the deploy branch ever. If you accidently merge deploy back to master, you’ll have a tough time undoing the damage.

Capistrano config?

Well, if you maintain your own remote repo of another project, then make sure that repo has your deploy branch at configure capistrano like such:

set :branch, "deploy"

If you don’t want to maintain your own remote repo, but want a local deploy branch, you’ll have to switch to copy deployment recipe (something like this):

set :deploy_via, 'copy'
set :copy_strategy, :export
set :copy_cache, true
set :copy_exclude, ['.git']
set :repository, '.'

BIG FAT DISCLAIMER: I’ve never used the above copy strategy myself, so I cannot vouch for it!

Results?

Well, this neat feature of git allows us to deploy and run our OSS projects as if we were the only users. Sensitive information is not exposed to the world, but is still recorded by hoptoad. It allows us to get the real exceptions as they happen in the wild, without guessing what happened when some logs a “It doesn’t work!!” ticket.

Today I finally had to “extract” a project from one of our biggest repos as part of a git migration plan. I’ve converted most of the other smaller projects in the same repo over using just their trunk, and it has worked without any noticeable issues. Now the project in question has several active branches and important tags. Our repo layout is something to be a shamed of, and git-svn likes “standard” subversion layouts.

I found this thread on KernelTrap, where one user has a similair layout to ours and faced the exact same predicament. The thread is interesting, and the people offer some good tips and advice. Although most of them just seemed “wrong”.

I proceeded to get a copy of our live repo onto my laptop for a simple test. Using a quick svnadmin dump/load combo I had a copy to play with. I sat with a team member, and several svn manipulations later we had restructured that project’s layout to be more svn-like. I then commenced to use the standard git-svn import tool and it pulled in all the branches, tags and trunk for the project in without breaking a sweat.

So, importing from svn with full history from a non-standard repo layout isn’t a daunting task after all.

Just one friendly warning though, if possible, get rid of as many unused branches and tags as possible before importing into git. The full history can get very messy in some cases, and in others a clean slate will be welcomed by the team…

Hope this helps someone else to jump ship easily

I checked up on ActiveRecord::Tableless and saw a fork that had some promising changes in, so I set out to pull those changes back to my repo. Seemed simple enough, I followed Steven Bristol’s steps and it worked.

The changes made by Peter Wagenet were simple and very useful, thanks Pete!

I’ll start working on specs for the project closer to the end of the week, for now my focus is on getting BIND DLZ on Rails ready for its first public appearance.