RabbitVCS

hi all, long time no see.  Some of you might have been wondering if RabbitVCS was dying or dead, and it isn’t, though truth be told it is limping a long a little.  Right now, Jason and I are the only ones actively writing code, and neither of us has much to time contribute to the project.  For myself, I used to work from home and could budget a certain amount of time during the day to working on RabbitVCS and other projects.  However, in late June of this year I got a “real” job with a “real” commute and all of a sudden my available time to work on side projects dropped over a cliff.  The good news is that about a month and a half ago I realized that on my bus trip to work in the morning (~25 minutes) I could get some programming work done.  So I purchased a netbook (Acer AIO 533), tethered it to my Android phone, and it has been a pretty successful idea.  I’ve been fitting in about 1.5 to 2 hours of side-programming per week this way, which is just enough to keep me happy.  I would love to be able to do more, and sometimes I’m able to, but this is good enough for now.

Aside from my personal update, here are the latest development updates to whet your appetites.  First of all, git support is coming along slowly but surely, and it will be available for v0.14.  Since git adds so many new concepts to the UI and to our code, we’re going to have a fairly long beta period where I hope people will be interested enough to try it out, suggest improvements, and maybe even be energized enough to get involved in some coding.  I can’t make any guarantees, but I think this might happen before Christmas.  The git support for v0.14 will be somewhat rudimentary, but it should allow you to do most of the things you need for git version control.

I also spent some time this past weekend and worked on making the RabbitVCS nautilus extension truly non-blocking, and I succeeded!  The trick of it is that while attaching the correct emblems to files has been non-blocking for a while, the parts of the extension that ask for context menu items has not been.  What this meant is that when you were loading a working copy, everything would be fine until you actually started clicking on stuff.  Once you did that, Nautilus would freeze for some amount of time until the menu was generated.  Unfortunately, until recently, there was no way around this due to limitations in the nautilus-python bindings.  I say “until recently” because in January of this year I took over development of the nautilus-python bindings and removed the limitation.  So with the release of nautilus-python 0.7.0 in May, we can finally populate context menus in a non-blocking way.  The catch is that this will only work if you have nautilus-python 0.7.0 or greater installed.  I just checked the package databases for Fedora and Ubuntu, and v0.7.0 is available for Fedora but not for Ubuntu (I just emailed the nautilus-python maintainer for Debian, so maybe it’ll be available in the next release).  However, we can probably set up 0.7 in a PPA for folks that want the newest shiny ;)

In summary, things are moving in the right direction, but just quite slowly.  There are definitely opportunities available for people who are willing to jump in and lend a hand (programming, packaging, whatever) so don’t be shy.

This entry was posted on Monday, November 15th, 2010 at 9:34 am and is filed under Status Update. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.