svn and tons of ignores

I never realized what a pain it was to maintain svn:ignore properties until I started using git (which makes it really easy to collect cruft metadata after a build).

After some searching on the web, I found this script:

#!/bin/bash

# svn-ignore - tell Subversion to ignore a file in certain operations.

# See: http://svn-ignore.notlong.com [svnbook.red-bean.com]

test -z "$1" && echo "Usage: $0 FILENAME" && exit -1

for fullname in "$@"

do

dirname=$(dirname "$fullname")

filename=$(basename "$fullname")

(svn propget svn:ignore "$dirname" | egrep -v '^$';

echo "$filename") >/tmp/svn-ignore.$$

svn propset svn:ignore -F /tmp/svn-ignore.$$ "$dirname"

rm /tmp/svn-ignore.$$

done

That coupled with:

for i in `svn status` ; do  if [ $i != "?" ];  then echo $i ; svn-ignore $i ; fi ; done

really saved me a lot of work.

A New Adventure

Some may have noticed that I haven't been around the Mono irc channels lately. I recently started working at Applied Signal Technology in Salt Lake City on July 7th.

One project I work on is an embedded board with some Xilinx FPGAs, one of which has an embedded ppc processor. It runs embedded linux and does signal processing in the FPGA. The kernel and embedded linux has been a long time favorite of mine.

The other project is a state-of-health hardware and environment monitoring system written in C++/QT. Having been using Python for monobuild and been in the Gnome/Mono circle for a few years, it has been quite the shift to use C++. I found an interesting white paper comparing C++/qt and Java, but have not formalized any opinions yet. Comments?

I wanted to give an update on my disappearance as well as express my graditude to Novell, my fellow co-workers, and the Mono community. It was a great 3 years and an awesome experience. Thanks especially to Andrew and Marc to taking over the build and release processes. We spent my last week or two at Novell transitioning things over and I've also spent some time since then helping them out. I'm fully confident they will do a superb job with Mono 2.0.

Good luck to everyone with the upcoming release. I wish y'all and the Mono project the best.

gvfs

I was checking out the openSUSE 11.0 Gnome LiveCD to gather some information about a Mono bug, and accidentally discovered gvfs.

I guess it's a replacement for gnome-vfs. From a quick glance, nautilus seems pretty much the same to me as when it used gnome-vfs. But, low and behold, when I opened up an sftp:// uri in nautilus, that 'share' was available via fuse in /home/linux/.gvfs!!! How cool is that??

This is probably old news, but I'm pretty excited about this. I guess there'll also be a kio interface. It seems gvfs has some really great potential to bridge the vfs gap.

Great work!

Gmail and IMAP

I've been using google hosted for my personal email for some time now. Cheryl was using their web client and I was fetching all my mail over pop to a local dovecot server.

After I heard they were going to support IMAP I decided that maybe I will finally migrate all my emails (back to 1996) to the google servers.

I noticed that messages copied via imap had incorrect dates when viewed from the web client. That hindered my decision for some time, but Andrew mentioned that they were going to eventually fix that. The dates still appear correctly in imap cilents, so I wasn't too worried. I'll mostly use an imap client, but it will be nice to be able to check and send mail from a web client.

(When hosting my own mail with dovecot, I had squirrelmail set up, but my mail was often rejected because it was sent from a dynamic ip. The unreleased squirrelmail beta had the option of configuring one authenticated account for outbound smtp, but using that feature with gmail was a little clunky because it seemed the mails weren't masqueraded properly.)

One of the things I really like about using gmail over imap is the ability to tag spam by moving it to the [Gmail]/spam folder. I had pretty good luck with spamassassin and although it was fun getting to work, I had some false positives and decided I didn't really want to think about spam any more.

The last of my concerns were answered by this help thread:

http://mail.google.com/support/bin/answer.py?answer=77657

I just hope I don't start deleting messages while using other email servers and expect them to be in my 'All Mail' folder :)

The performance is ok, but not as good as using my own dovecot server serving one account. But since I get the above features and I don't have to worry about backups or my computer going down, that's something I'm willing to live with.

Update:

Some people have asked how I did the actual migration. I configured two imap servers in Evolution and manually copied messages/folders from one account to the other. This took several hours of babysitting the process for roughly 250MB of mail.

It may be worth looking into imapsync.

Update:

Andrew sent me this: google-email-uploader

Accessibility Team looking for packager

Jared Allen asked me to keep an eye out for anyone interested in packaging for Novell's accessibility project. Send me your resume if you're interested.

Novell Hack Week #2

I decided to continue on with my hack week idea from last year.

I spent the better part of a day getting the devel environment set up (compiling and setting up myth from HEAD, setting up the latest compiz-fusion from the build service, and gathering some test HD videos for myth) only to find out that it looks like it's been fixed already! We'll have to wait until the next major release of myth, but it's in there. Moving on.

The next item was a leftover idea that had been kicking around from the Tomboy hack night last December.

For that event I wrote a little python script that rapidly created notes over the Tomboy dbus interface. I gathered some data about how Tomboy performs with a large number of notes. The main findings were:

1. Start up time was pretty dismal with a large number of notes (even 1000, which isn't that inconceivable)
   
2. Note creation time steadily increased as the number of notes increased
3. The time it took to delete notes was much longer than desired when you had a large number of notes
4. Tomboy performed quite well during typical use cases, even with a large number of notes
   

Hence my Hack Week #2 project: add an sqlite backend to Tomboy to help address some of the performance issues in Tomboy.

Boyd had mentioned that Everaldo and crew had done an sqlite backend for the maemo Tomboy port. My first objective was to port that code from the 0.7.x codebase to trunk (0.9.x?)

It turns out the maemo port was done mainly to work around a bug in Mono running on the n800. The maemo sqlite port allowed a mechanism for storing multiple notes inside one file in order to work around the aforementioned bug. That alone wouldn't solve the above issues. (In fact, this sqlite backend was significantly slower than the file backend unless delayed writes were enabled for the sqlite db. With delayed writes, they performed roughly the same.)

I spent the rest of hack week getting introduced to git and git-svn (which really rock!), getting my feet wet with C#, reading Tomboy source code, investigating Linq, and writing the C# code to do the db schema creation and schema upgrades. The main conclusive points of interest are:

1. To utilize the sql db, queries are needed to pull only the notes into memory that are of interest (otherwise, with all notes in memory, I'm guessing that's a main reason as to why the previous list of shortcomings occur, especially startup time)
2. Find out if the current note buffering scheme is needed during note editing. If not, the code could be simplified by persisting changes straight to the db.
3. We'll likely need an interface to transparently search and interact with notes in memory or from the db (meaning, I'm guessing the findings from #2 may be futile)
   
4. Provide note migration from xml to db
   

I seem to get mixed reactions from those who hear about a change like this. Some say, "Yay, with 200 notes, Tomboy is slow with some things!". Others, "Tomboy will likely move to using a db anyway." And, "With so much work and so little possible gain, why bother?" And lastly, "Eww, no db! Then I won't be able to ssh into my home/work computer and poke at the .xml note files!"

To alleviate at least the last point, Andrew wrote a sweet command line util: Tomboy Remote. (Because you shouldn't be poking at a program's internal data anyways!) Update: Source download.

In conclusion, there's quite a bit of work remaining. The main benefits of this week were that I got some C# exposure (finally!), experienced a great use case for decentralized scms, and got more familiar with the Tomboy codebase. More for next time!

On another hack week semi-related note, I just upgraded my home system. (I got an intel mb, Core 2 Duo (E6550), 4 GB of ram, and an nvidia 6200le card for $300 after rebates. Thanks Joel and Steve!) Anyway, the onboard sound only has one audio port. Luckily Herbert was kind enough to add my last years hack week PulseAudio patch to the Packman rpms. Great timing!