The point is that we don’t want a “David Tanzer”, a “david tanzer” and a “dAvid tanzEr”. The normalize_login_and_email downcases both the login name and email address, associated to an account, to put them in canonical form (before checking the database to see if there is already an account with that name/email).

While downcasing the email address is clearly the right thing to do, it’s not so clear that’s the “right” thing to do for the login name. I’ve fixed it so that we just make a case-insensitive check on uniqueness.

But, as an Instiki user, you are probably well-familiar with the syntax. Heterotic Beast uses Maruku as its Markdown processor and itex2MML to process equations. It even has the same WYSIWYG SVG editor that Instiki uses. So, except for a few bits of Wiki syntax ([[...]] for wikilinks, [!include ...] to include other wiki pages, etc), it should work exactly the same as what you’re used to.

The sqlite3 rubygem won’t compile without thelibsqlite3 C-library. (Unlike many rubygems, which are pure Ruby, this one contains a C extension that links to the aforementioned library.)

Windows (unlike other operating systems) doesn’t come with that library installed. Some Ruby installers, for Windows, install it; evidently, some don’t. For those, you’ll have to install it yourself.

If you google around, you’ll find plenty of useful advice on this topic. Unfortunately (since i don’t have any familiarity with Windows), I’m not a useful source for such advice. But, yes, as far as I can tell, installing the Windows SQLite3 package is a prerequisite for getting the sqlite3 rubygem installed.

How does this installation work? What i gather you use “GIT” to download all the packages or i think bundles is the term and then ruby installs them on the system?

Bundler lets you manage/install rubygems, without installing them on the system. Instead, they are installed in your application’s vendor/bundle directory.

Porting Instiki to Rails3 has long been on my TODO list. But (as you’ve seen), it’s not a small job. So it keeps getting pushed back in favour of other things. So I’m really happy you’re working on this!

I guess the first question is: do you want to convert the whole history (ie all previous revisions of each page) to Markdown, or just the current version?

If you just need the current version converted, you can go to the “Export” tab, and click on “Markup” to create a zip archive containing the (Textile) markup of each page.

If you want to convert the previous revisions, too, then you should look at the rake tasks described on this page. Those instructions are geared towards migrating from one database (e.g. sqlite) to another (e.g. MySQL). But they would also be useful in converting the content of the revisions` table, without changing database engines.

Sorry, I follow exactly the steps you outlined, and it’s adequate+subcategory (and its variants) that get cleared from the cache, not adequate+subcategory+>+history.

The scenario you outline (involving the old name being forgotten before the cache gets swept) is exactly what the before_save action is supposed to avoid. Then the cache gets swept again in an after_save action.

Now, the only thing I can think of is that I tested this under SQLite3, rather than MySQL. Perhaps the driver for the latter does something funky. But that seems unlikely…