Change to new posterous API
YAML front matter fix, cleaned up slug generation, added tags and store some posterous information from the original post.
Merge pull request #1 from simensen/alagu-master

Fixed critical bug, added a few minor features
Merge remote-tracking branch 'origin/alagu-master' into alagu-posterous-importer-rebased

Conflict created due to #472.

Conflicts:
	lib/jekyll/migrators/posterous.rb
Handle Posterous rate limiting
Truncate post slugs when importing from Tumblr.

Fixes #481.
No need to have a variable assignment, especially if it has the same name as the method parameter.
fix issue 457: Custom destination in _config.yml causes jekyll server to auto-regenerate continuously
pygments options for pygments.rb
Added a configuration variable: keep_files (default: ['.git']), based on this pull request: https://github.com/mojombo/jekyll/pull/556
removed puts
Merge branch 'alagu-posterous-importer-rebased' of git://github.com/simensen/jekyll
Merge branch 'master' of git://github.com/mojombo/jekyll
Look for plugins under the source directory

When generating the site, Jekyll will now look for plugins under the
source directory by default. The plugin location can still be changed in
_config.yml
faster_lsi: Massively accelerate LSI performance.

Currently, Classifier::LSI rebuilds the index every time an entry is
added.  This runs into massive performance overheads on my website;
theoretically, disabling automatic index rebuilds, and explicitly
rebuilding the LSI index at the end of the LSI repopulation should
speed things up nicely.

As a side note, here, I use pandoc-ruby to provide a more featureful
Markdown transformer, so be mindful that the numbers I quote here have
artifically imposed I/O overheads.

With just the 76 posts I wrote this year (abysmal, I know), I come up
with the following figures:

    Without faster_lsi:
      jekyll --lsi  16.91s user 0.88s system 97% cpu 18.302 total
    With faster_lsi:
      jekyll --lsi  2.72s user 0.77s system 88% cpu 3.940 total

With 109 posts, we begin to see even better improvements:

    Without faster_lsi:
      jekyll --lsi  51.00s user 1.47s system 98% cpu 53.060 total
    With faster_lsi:
      jekyll --lsi  5.04s user 1.12s system 91% cpu 6.735 total

At this point, we begin to see I/O overheads being slower than LSI
when faster_lsi is active.  I call that fairly conclusive.  But wait,
there's more.  I have 273 posts lying around... I wonder what happens
if I feed them all in.  With faster_lsi, it was nice and clippy.
Without it, I simply gave up, and went and refilled my cup of tea.
And it was still going.

    Without faster_lsi:
      jekyll --lsi  1277.86s user 10.90s system 99% cpu 21:30.29 total
    With faster_lsi:
      jekyll --lsi  34.62s user 4.43s system 96% cpu 40.430 total

That is, in anyone's books, a major improvement.  Note, however, that
I don't know just how well this will perform with `jekyll --auto`
because I don't know how it does the LSI rebuilds.  I _think_ (but
please, don't commit me on this) that the LSI is rebuilt every time
Jekyll picks up a file change.

So, all up, the performance improvement is massive, and scales
depending on how many files you have.  At the last point, the
improvement is just on 3200%.

A more optimal solution would be to cache the LSI index and/or content
data somehow.  I'll leave that to when faster_lsi takes over ten
minutes to run.
Making sure errors don't halt the import.

Wrapped file operations in a begin/rescue block.
Convert slashes in titles to dashes when migrating from WordPress

When a post has a title that contains a slash, such as 'This is my cool
blog post part 1/2', convert the slash to a dash so that the post
filename is created correctly.

Fixes issue #680
use Array.join instead of Array.inject, add .svn to defaults
Add commander dependency
Add bin/jekyll2 and initial BuildCommand

The `BuildCommand` class is responsible for handling the building of the site.
It can also optionally watch for changes to files and regenerate the site if
needed.

The `Command` class holds any methods which are used by any command
implementation.