Open Sourcery

The basic “cap deploy:cleanup” does its job well, but can leave traces behind.

I recently picked up that one of my servers in a Rails cluster had plenty more release directories than its peers, and they were very old. I was baffled, how does this happen when I run “cap deploy:cleanup” religiously after a release has stabilized… I decided to figure out why, and how to dodge it. Who knows how many other release directories are scattered around the network.

It seems that cap gets the directory contents of the “releases” directory from the first server in its internal list. It then uses that directory content to remove stale releases from all servers. This is a sane approach, but things do go wrong and releases will build up over time.

Running the task once for every host seems the quick solution without messing with cap itself.

$ cap deploy:cleanup HOSTS=10.0.0.1

This gives each individual host a fresh start. From here, lather, rinse, repeat.

Later

Nope, its not another post about how incredible git is, instead I’m just gonna highlight a quick way to get used to git and/or git-svn during the transition (yes, resistance is futile).

$ sudo gem install cheat

$ cheat git

$ cheat gitsvn

No need to open a browser, search through delicious or even google.

Hope it helps make git and/or git-svn more digestible.

UPDATE (2008-04-29)

I got beaten to the punch on using cheat, thought I’d just add some more links for your enjoyment

Git and Ruby on RubyInside
Printable Git Cheat Sheet (scarily similar to the Mercurial ones)