## February 4, 2009

### Takeover

Two years ago, I decided to adapt a well-know Rails-based wiki to my nefarious purposes. Twenty five months and 350 commits later, my fork of Instiki had diverged markedly from the original.

This was a source of considerable confusion. If, say, you searched for instiki, my site would show up in the first page of results. But the other, now radically-outdated, application would show up first. Perhaps I should have chosen to change the name.

Or perhaps not.

If you wander over to the main Instiki website, and scroll to the bottom of the page, you’ll notice something curious. It’s running my version of Instiki.

After some discussions, the current maintainer, Matthias Tarasiewicz, decided to adopt my branch (lock, stock and barrel) as the next version of Instiki.

The main Instiki Source Repository has moved to Github (yay!) and mirrors1 mine. The, soon-to-be released, “next” version of the main line of Instiki will be my Version 0.16.2.

My branch is now at Version 0.16.3, based on the latest Rails 2.3.0RC1. One cool new feature is that it automatically chooses between Mongrel (if available) and WEBrick (if not). You just type

./instiki --daemon

and it will automatically select the best available webserver to use.

You’ll always be able to get the latest and greatest version from my site. But, hopefully, releases of the main line of Instiki will never again lag too far behind.

1 One really annoying feature of Git is that it ignores empty directories in commits. Why do people put up with that? There are a bunch of such directories in Instiki (and, indeed, in most Rails apps), so Git seems particularly ill-suited as a source repository for such projects.

Posted by distler at February 4, 2009 11:42 PM

TrackBack URL for this Entry:   http://golem.ph.utexas.edu/cgi-bin/MT-3.0/dxy-tb.fcgi/1906

### Re: Takeover

The very earliest versions of the git repository format used a single tree object per commit, which listed the full paths of files, but did not list directories. It was replaced within the first weeks by a design where a tree object stores the contents of a single directory including subdirectories (which are stored in additional tree objects) with relative names. However, the old format remains in use for the index. But if you use the plumbing to construct a tree you can store empty subdirectories in it just fine.

And so it has become the standard answer to the question you raised that no one has been sufficiently irritated to patch the shortcoming out of existence.

Posted by: Aristotle Pagaltzis on February 5, 2009 8:41 PM | Permalink | Reply to this

### Re: Takeover

Congratulations!

It is rare for a physicist to do something useful… ;-)

Posted by: Andrea on February 5, 2009 9:26 PM | Permalink | Reply to this
Weblog: Sam Ruby
Excerpt: Jacques Distler: Congrats!  Hopefully someday, I’ll be as lucky with Venus. P.S.  Cute logo.
Tracked: February 8, 2009 11:01 AM

### Re: Takeover

I would use Instiki if it handled flat files without requiring a database. Love the MathML support.

Posted by: QnA on March 15, 2009 12:01 AM | Permalink | Reply to this

### Re: Takeover

Not sure why that’s an issue for you.

The default database is SQLite3, and requires no mucking about to set up.

And using SQLite3 instead of flat files makes backing up your wiki a breeze. Just copy db/production.db.sqlite3 (an ordinary file) to a thumb drive.

I saw your post at that other forum. All I can say is that DB access comprises a very small fraction of the total processing time of Instiki. Replacing SQLite3 with MySQL (trivial to do) or with flat files (would require a rewrite of ActiveRecord) would not noticeably speed up the application.

Posted by: Jacques Distler on March 15, 2009 12:17 AM | Permalink | PGP Sig | Reply to this

Post a New Comment