14
Apr

Hosting Git Repositories on Dreamhost

Over the weekend I went searching for a way to host remote git repositories on my Dreamhost (DH) account. I do a fair bit of development year round and up to this point have been hosting all my code on my DH account using Subverision. Over the past few weeks I’ve been making the move from Subversion to Git on my local dev machines, and figured it was time to start hosting my git repositories remotely as well.

It took a lot of searching around online and some tinkering, but I was able to get everything setup properly and in the hopes of saving everyone else some time, I’ll post my results here.

First, if you take a look at the DH wiki entry for Git, you will see the very first method described is to run Git on your DH account using WebDAV. If you’re like me, thinking about doing Git over WebDAV probably just left you scratching your head. I think the reason why this is advocated, is because of the way DH setups SSH accounts. By doing git over SSH to a DH account, only one person would be able to remotely push changes, which is fine for my needs. But, if you need to give multiple users access for pushes, then WebDAV would technically work for you. But, I opted not to go down this route.

I chose to simply compile Git locally into my DH account and connect to it over SSH. This blog post on Autopragmatic.com got me about 90% of the way toward completion, so the next few steps are taken directly from his post.

Step 1. Compile and Install Git on Dreamhost

The first thing that needs to be done is to compile Git locally into your DH account. I personally have a ~/src directory where I download and compile all my code and I have a ~/packages directory where I install my binaries. You may have a different setup so if so, just substitute those paths accordingly. Also, make sure to substitute <USER> with your DH username

$ cd ~/src
$ wget http://www.kernel.org/pub/software/scm/git/git-1.5.4.rc4.tar.gz
$ tar xvzf git-1.5.4.rc4.tar.gz
$ cd git-1.5.4.rc.tar.gz
$ ./configure --prefix=/home/<USER>/packages NO_CURL=1 NO_MMAP=1
$ make
$ make install
$ git --version

There are a few things to be aware of. First, the NO_MMAP=1 parameter is necessary to keep the DH process police from killing your Git process. Git normally creates two 250MB memory map files, and DH will kill your Git process since it sees it consuming over 500MB of memory. I also used the NO_CURL=1 parameter as I will not be needing my git repositories to have the ability to pull from other remote locations. If you do need this functionality, then you will also need to download, compile and install libcurl, but that is beyond the scope of this post. Also, make sure that you have the path of your installed binaries in your $PATH or that last command of git –version will fail. In my case, I have added /home/<USER>/packages/bin to my $PATH in my ~/.bashrc file.

Step 2. Create a new bare Git repository

Now that you have installed git, you can start making new repositories. You can, of course, store these repositories anywhere you want. I chose to create a whole new sub-domain under the Dreamhost Domains Panel. Some people prefer to instead create a git subdirectory under an existing domain. Any way is fine, the choice is yours. For the rest of this post I’ll simply be refering to git.example.com as the <PATH> of my git repositories. You will change this to your path.

If you plan on making multiple repositories, the easiest thing to do is simply automate the process by adding the following function to your ~/.bashrc file.

newgit()
{
    if [ -z $1 ]; then
        echo "usage: $FUNCNAME project-name.git"
    else
        gitdir="/home/<USER>/<PATH>/$1"
        mkdir $gitdir
        pushd $gitdir
        git --bare init
        git --bare update-server-info
        chmod a+x hooks/post-update
        touch git-daemon-export-ok
        popd
    fi
}

This way you can simply login to your DH account and type:

$ newgit my-new-repos.git

and a new bare repository will be created for you in your <PATH>. Or if you prefer to create a new repository from your local box you could even do it over SSH:

$ ssh <USER>@<MACHINE>.dreamhost.com newgit my-new-repos.git

Step 3. Pull and push to your new repository

Theoretically, you should now be able to pull and push from this bare repository using the following command:

$ git clone ssh://<USER>@<MACHINE>.dreamhost.com/home/<USER>/<PATH>/repo-name.git
$ git push origin

However, I found this did not work for me and resulted in the following errors:

Initialized empty Git repository in ~/src/newrepo/.git/
Bad port ”
fatal: no matching remote head
fetch-pack from ’ssh://<USER>@<MACHINE>.dreamhost.com:/home/<USER>/<PATH>/my-new-repo.git’ failed.

The problem is that the new repository is bare and has absolutely no data in it at all. That led me on another search that brought me to this excellent writeup that got me the rest of the way home. What I did was simply changed directories into my local git repository. If you haven’t even started your codebase locally yet, I would recommend going ahead and doing that.

Create a new directory and create or add in your files, then do the following to setup a local git repos:

$ cd /my/code/path
$ git init
$ git add .
$ git commit -m "initial import"

That will create a local git repository in your working directory and commit the initial files. Next follow the next set of commands to add your DH repos as a remote and push your initial codebase up to it.

### assuming ssh://server/remote.git resolves to an empty, bare git repo
### and that we are chdir()'d to the local repository:
$ git push --all ssh://<USER>@<MACHINE>.dreamhost.com/home/<USER>/<PATH>/my-new-repos.git
$ git remote add origin ssh://<USER>@<MACHINE>.dreamhost.com/home/<USER>/<PATH>/my-new-repos.git
$ git config branch.master.remote origin
$ git config branch.master.merge refs/heads/master
$ git fetch
$ git merge master
$ git branch -a
* master
  origin/master

Now you can simply work locally and do a

$ git push

to push to your DH remote. And if you ever need to you can simply execute a

$ git pull

to pull down and merge remote changes.

05
Apr

prototypeGrowl

For some current updates we are doing at wis.dm, I came across a need (or desire) for a Growl type effect for Prototype.

I was very surprised that no one had implemented one yet. I found an implementation for jQuery, YUI, and mooTools. I actually did find a decent implementation called protoGrowl, but it was much too overweight for what I needed since it was originally developed to be used with the Midgard CMS system.

In the end, I really liked the mooTools implementation and decided to try and port it to Prototype. Unfortunately, my Prototype 1.6 skills aren’t as solid as I would like so I sought out help online and came across Thomas Reynolds on gitHub. He agreed to help and so the project began. A few hours later we had the first working version of prototypeGrowl. After a nights rest and some more coding we have a pretty nice implementation of growl for prototype.

Check it out and feel free to fork the repository on gitHub and contribute any tweaks or updates you want.

07
Dec

Small Tweak to atom_feed_helper Plugin

I ran into an interesting “issue” this past week while using the atom_feed_helper plugin for Rails.

The plugin is designed to be a quick, easy-to-use way to generate ATOM feeds for your controllers. An interesting issue with the plugin is that it doesn’t allow you to manually set each ATOM entries link URL. The plugin sets the link field manually using the _polymorphic_url()_ method.

@xml.link(:rel => 'alternate', :type => 'text/html', :href => @view.polymorphic_url(record))

My problem with this arose when trying to generate a feed for a nested resource. I wanted to generate an ATOM feed for all Comments left on a certain Question in my Rails application. Comments are not viewed individually, but rather as a threaded list in the Show method of the Question to which they belong. The URL generated by the _polymorphic_url()_ call didn’t quite handle this properly.

The more I thought about this, I can see other instances as well where you might want to manually specify a certain URL for each entry link. So I went about making the following change to the plugin and am going to be submitting the patch to the Rails team as an enhancement.

def entry(record, link = nil)
  @xml.entry do
    @xml.id("tag:#{@view.request.host_with_port},2007:#{record.class}#{record.id}")
    @xml.published(record.created_at.xmlschema) if record.respond_to?(:created_at)
    @xml.updated(record.updated_at.xmlschema) if record.respond_to?(:updated_at)

    yield @xml

    entry_link = link.nil? ? @view.polymorphic_url(record) : link
    @xml.link(:rel => 'alternate', :type => 'text/html', :href => entry_link)
  end
end
03
Dec

FeedCache Nearing 1.0 Release

FeedCache is nearly the version 1.0 release.

Currently, version 0.9.5 is available on wordpress.org. There are two new features that will be included in the 1.0 release which should be available before the end of the year.

If you have been using FeedCache and have any features you would like to see included, please let me know. Also, if you’ve found any bugs or issues with the plugin, let me know that as well so I can fix the problems.

16
Nov

FeedCache v0.7 BETA

There is a new version of the FeedCache Wordpress plugin available for BETA testing for all who are interested.

http://wordpress.org/extend/plugins/feedcache/download/

To get the BETA version, instead of clicking the “Download Plugin” button, click the “Development Version” link that is listed under the “Other Versions” sections. I’ve been testing it out, and I would like some folks to help me test before I update and make the new 0.7 version the newest stable version.

The whole setup of the plugin has changed now that there are multiple sections of feeds so your best bet is to just deactivate the existing plugin and delete the whole /feedcache directory from your /wp-content/plugins directory and just install the new 0.7 as if you had never used it before.

Let me know if you have any trouble installing and/or using it and if the installation instructions aren’t clear enough.

15
Sep

Gathering Wis.dm

It’s now official. I’ve left RatePoint and joined the team at Wis.dm.

I really enjoyed my time at RatePoint getting the company up and running. Over the past 10 months we released 4 different Rails apps: a social website ratings service, a badge reputation service, an avatar rating service for SecondLife, and an API to automate signups for the badge reseller program.

Wis.dm is another Ruby on Rails web startup that is taking on the question/answer space. I’m excited to get started there and see where we can take the site.

12
Sep

FeedCache Wordpress Plugin Now Available

The FeedCache plugin is now in the official Wordpress directory and can be downloaded for public use.

The plugin code is stable at this point, but I’m still tweaking some error checking in the Ruby CRON script. Right now there are a few issues with HTTP timeouts and XML feed parsing that can be improved upon.

Look for the next version of the plugin to be released sometime by next week.

04
Sep

FeedCache Wordpress Plugin v0.3

OK,

So there were a few issues with v0.2.

I’ve updated some bugs and released v0.3 to those who are testing it for me. Hopefully I’ll have a public release soon.

03
Sep

FeedCache Wordpress Plugin v0.2

I’ve finished up version 0.2 of my FeedCache Wordpress Plugin. The plugin still isn’t publically available for download yet, but I anticipate releasing it in the next few days.

If you are interested in seeing v0.2 in action, you can visit MMA HQ. Currently MMA HQ is using FeedCache to cache 5 different RSS feeds with the cached listing updated every 30 minutes.

Stay tuned for the public release of the plugin and feel free to email me with any questions or feature requests.

19
Jun

TeleSign Plugin Update

I’ve been making good progress on the Telesign Telephone Verification plugin that I’ve been talking about. I’ve completed what I consider to be all the “core functionality” pieces. At least all the pieces I need right now for the app I’m working with (www.ratepoint.com).

The plugin is active right now in production and seems to be working well. There are still quite a few other tweaks and features I’d like to add to the plugin, but the actual telephone verification part seems to be working well.

I’m wondering the best place to host the plugin and am looking for any suggestions. Should I just host it on my own server? Should I use Google Code or something along those lines? Let me know.