Poojan (Wagh) Blog

I recently detailed the high-level setup of my latest GTD roll out. This follow-up post has a high “geek factor” and contains the details of how I do this using computer automation (Python scripts).

Read the rest of this entry »

Update: I recovered my lost commit by following the directions here. In addition, I had to create a branch from this commit using chekcout -b. I then switch to the master branch and merged the temporary branch into master

It has been written posted that git revert is not the same as svn revert. That’s true.

However, there have been suggestions that the equivalent is git reset --hard commit. I just did this. It isn’t good. Luckily, I didn’t lose muchany data. However, doing a --hard means that you reset the index back in time, too–not just your working copy.

I’ll admit that I don’t understand git very well. I’m not entirely sure (now that I’ve gone back in time) how to bring myself back to the future.

Essentially git reset means that you want to get rid of changes in your repository: not merely go back in time, see what things looked like, and move forward in time.

Anyway, a safer thing (for me to have done) would be git checkout commit.

The git manual specifically says:

–hard

Matches the working tree and index to that of the tree being switched to. Any changes to tracked files in the working tree since commit are lost.

Wonder if I’m too feeble to be MacGyver and need a James Bond. On the other hand, now that I’ve learned this lesson, maybe I’m better off sticking here.

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.