rss
Migrating contacts from Android 1.x to Android 2.x
I'm finally getting around to upgrading my trusty old Android Dev Phone 1 from the original Android 1.5 firmware to Cyanogenmod 6.1. In doing so, I wanted to take my contacts with me. The contacts application changed its database schema from Android 1.x to Android 2.x, so I need to export/import. Android 2.x's contact application supports importing from VCard (.vcf) files. But Android 1.5's contact application doesn't have an export function.
So I wrote a minimal export tool.
The Android 1.x contacts database is saved in /data/com.android.providers.contacts/databases/contacts.db which is a standard sqlite3 database. I wanted contact names and phone numbers and notes, but didn't care about any of the other fields. My export tool generates a minimalistic version of .vcf that the new contacts application understands.
Example usage:
./contacts.py contacts.db > contacts.vcf adb push contacts.vcf /sdcard/contacts.vcf
Then in the contacts application import from that file.
If you happen to have a need to export your contacts from an Android 1.x phone, this tool should give you a starting point. Note that the clean_data function fixes up some issues I had in my particular contact list, and might not be very applicable to a different data set. I'm not sure the labels ("Home", "Mobile", "Work", etc.) for the phone numbers are quite right, but then, they were already a mess in my original data. Since this was a one-off task, the code wasn't written for maintainability, and it'll probably do something awful to your data--use it at your own risk.
Building a standalone Subversion binary
There are times that you want to be able to experiment with different versions of Subversion. One scenario I've run into a number of times now is wanting to use the new patch feature of Subversion 1.7 on an "enterprise" distro or an older distro. But I don't want to upgrade everything; I just want to use it for a specific task and return to the distro-provided Subversion 1.6 for instance.
Building a standalone binary is pretty straight-forward -- enough so that it would not seem worthy of a blog post. However, I recently found myself spending an embarrassingly long time beating my head against Subversion to get a binary of the form I wanted. And the particularly galling thing about it was that I had successfully done what I was trying to replicate a mere year earlier. So, in the interest of saving others the frustration, and my self a third round of frustration, here are the steps to build a stand-alone Subversion binary:
First, you do need to be sure you have some libraries and headers available. For Fedora, you can run:
yum install apr-devel apr-util-devel neon-devel
Edited to add: If you're building Subversion >=1.8, you will also need to add sqlite-devel libserf-devel to that list.
Other distributions should be similar. I'm sure there are other development packages required, but I must have installed them at some point in the past.
Once you have your dependencies ready, go download the Subversion sourcecode. With your freshly downloaded tarball:
$ version=1.7.6 $ tar -xjf subversion-$version.tar.bz2 $ cd subversion-$version $ ./configure --disable-shared $ make svn $ mv subversion/svn/svn ../svn-$version
This yields a binary named svn-1.7.6 that you can move to your ~/bin or where ever, and you can then use that specific version of Subversion when you need it. The binary will be somewhere around 8MB, give or take. This is a standalone binary, but not a completely statically linked binary; it uses the shared libraries of the system, but has all the Subversion code statically linked to the binary.
This process also works for version=1.6.18, and presumably other versions as well.
One of the interesting new toys in 1.7 is svnrdump. You can build that in essentially the same way, just with make svnrdump or make svn svnrdump instead of make svn. You'll find the binary in subversion/svnrdump/svnrdump.
Now, go, experiment with svn patch and svnrdump and all the other 1.7 goodies!
