Poojan (Wagh) Blog

I’m personally using Git to version-control my WikidPad files. However, Mercurial (and especially TortoiseHg) is equally well suited for this function. In many respects, Mercurial is simpler to use than Git. The only shortcoming I had with Mercurial is that there’s no managed branches; to branch, you create an independent copy of the whole repository (clone it).

Nonetheless, for most people, Mercurial will not only suffice but give quicker rewards than Git.

I don’t use Subversion for this purpose, because subversion has a centralized approach which requires a repository, separate from a working copy. Importing, merging, branching, etc., with subversion is a bit of a hassle. This “hassle”, of course, is purely personal taste; others will (strongly) disagree. In fact, for many other purposes, I strongly prefer Subversion to Mercurial/Git/etc.

Goal

By the time you’re done with the following steps, you should be able to:

1. Place a WikidPad Wiki under version control
2. Commit changes as files change
3. Revert to prior versions Read the rest of this entry »

There was  apost over at wikidpad-devel | Google Groups, where someone talked about using Drop Box to sync WikidPad databases. The person used the original_sqlite database format of WikidPad.

I personally like the “Original SQLite” format for storage. This internal database has the following properties:

The data for your wiki is stored in plain text under the data
directory of the directory your Wiki config is stored in. There is one
file per wiki word. The database to index the wiki is stored in the
file “wikiovw.sli”.

Which is great, because I get all the features of SQLite search/indexing, but all my pages are in a text format.

The great thing about this setup is that I can use version-control to keep them in sync. I originally thought about using SubVersion. However, I decided to go with a distributed version control system instead. I took a hard look at both Mercurial and Git. I decided on Git since it does implicit renames rather than explicit renames. This means that I don’t have to write any hooks in WikidPad for when there is a rename/copy of a page. Of course, I could do without this feature in Mercurial, and it would still work. It’s just nice that Git does provide the benefit of diff-based storage without the need for explicit copies/renames/moves.

So, I keep two WikidPad notebooks going: a Work one, and a Personal one. The Personal one is on all the computers at home (Windows Laptop, Windows Desktop, FreeBSD server). It is also on a USB thumb drive. One of the features of git is that the entire repository comes along with a working copy. Let’s say I’m editing a WikidPad page at home that I already edited on another computer. I don’t have to worry about syncing. I can check in both changesets and merge later. This is a feature that Mercurial also has.

That’s the great thing about text files: they work very well with version-control systems.

I also use the ScrapBook extension from Firefox to archive/annotate pages from the web. The extension saves an index of the pages in RDF format. RDF is a form of XML, which was touted as a better way to save data because it is text-based. Curiously, XML doesn’t work well with any merge tool I’ve come across. I’ll post about my descent down this rat-hole (and how I got around it) later.