RabbitVCS

We’re shifting to github.

The existing issue tracker and downloads will remain in place on google code, but new issues and releases will be via github.

hi all, so I’ve made yet another packaging related release with v0.15.0.4 which fixes some minor issues.  I also found out that if you are installing from the tarball on Ubuntu, then you need to add an argument to the setup.py call, otherwise it will ignore the system prefix and use /usr/local no matter what, which will cause many problems.

Ubuntu users should use the following command to install:

$ sudo python setup.py install –install-layout=deb

All other users should do:

$ sudo python setup.py install

Thanks,Adam

hi all, I just wanted to explain why so many of you are getting segmentation faults when you try to run the nautilus 3 client.

The pygtk world used to be quite simple and nice, with good documentation and well known best practices.  These were “static” gtk bindings that someone had to set up by hand (including me for nautilus-python).  These bindings were a pain in the butt to maintain over time but they worked pretty well and were predictable (good for coding against them).  However, a couple years ago the pygtk maintainers decided to abandon these bindings and start from scratch with “dynamic” bindings that would execute the original C code of the gtk library, which would have the effect of dramatically reducing the amount of hand-written binding code the pygtk developers would have to maintain.  These new dynamic bindings have been released for a while but are still pretty new to the world, but for the most part they work pretty well.  As you might be able to tell, the original Nautilus extension used the static pygtk bindings to run, and the new Nautilus 3 extension uses the new dynamic bindings to run.
Running Nautilus 2 with the static bindings works great, and running Nautilus 3 with the dynamic bindings works great as well, but problems start to occur when you try to run Nautilus (2 or 3) with both the static and dynamic bindings at the same time (this is possible).  Unfortunately this is what is happening for many of you right now.  Some extensions are written with the expectation that they can run with a mix of static and dynamic bindings, and if Nautilus 3 loads extensions that try to use the static and dynamic versions of a set of bindings at the same time, it will crash.

I’m not entirely sure what the solution to this is, though it will become less of a problem over time, as people switch completely over to the dynamic bindings.  However, for now, things will be a bit messy and you will have to decide which extensions you want to run.  Right now, the Nautilus 3 RabbitVCS extension uses dynamic bindings.  If you see the following error:

** (nautilus:2259): DEBUG: Syncdaemon not running, waiting for it to start in NameOwnerChanged
/usr/lib/python2.7/dist-packages/gobject/constants.py:24: Warning: g_boxed_type_register_static: assertion `g_type_from_name (name) == 0′ failed
import gobject._gobject
/usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:40: Warning: specified class size for type `PyGtkGenericCellRenderer’ is smaller than the parent type’s `GtkCellRenderer’ class size
from gtk import _gtk
/usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:40: Warning: g_type_get_qdata: assertion `node != NULL’ failed
from gtk import _gtk
Segmentation fault

Then it means you have another extension running that is trying to use the static bindings.  If you see this error (check in ~/.config/rabbitvcs/RabbitVCS.log) and your Nautilus isn’t able to run, first disable all nautilus-python extensions, then try to run RabbitVCS again.  Then one-by-one, enable your other extensions until Nautilus crashes again.  You should then report the issue either to myself or to the maintainer of said extension.

Hopefully this will resolve itself within a year or so, but until then it will be a somewhat bumpy ride.

Adam

Things have calmed down somewhat since the v0.14.2.1 release and I’ve been wanting to post an update on my RabbitVCS-related goings on.  So what have I been up to?

Well, some of you may have heard about GNOME 3, which is scheduled to be released within a month or two. Unfortunately, the current versions of both nautilus-python and RabbitVCS are completely broken in GNOME 3 because PyGTK has not and will not be ported to GTK+3, and nautilus-python is what RabbitVCS uses to interface with the Nautilus extension framework.  The good news is that not only am I the maintainer for RabbitVCS, I’m the nautilus-python maintainer as well!  I’ve just about gotten the new bindings to work correctly on GNOME 3 and will put out a release as soon as possible.  They will require Nautilus 3 and the next bug-fix release of PyGObject 2.28 (I uncovered a bug in the current version).

The result of all of this is that I will need to port RabbitVCS’s Nautilus client to GTK+3, and possibly the rest of RabbitVCS as well.  It’s going to get a little hairy for a while as we figure out what to do.  So if anyone has any ideas, I’m all ears.

I’m also the maintainer of thunarx-python, which I started originally as a project on github.com, and I recently did my first release as an officially hosted Xfce project!  I just released v0.2.3 last weekend and the project is stable and ready to be packaged by distributions.

Once I get this nautilus-python release out the door, I will start focusing on RabbitVCS bugs once again and maybe make some more progress on advancing towards v0.15.

Happy St. Patricks Day!

If you are reading this now, that means the migration was a success!  Prior to this month, the rabbitvcs.org domain and website was hosted by Bruce (a long lost but much missed developer for the project).  Since Bruce is no longer associated with RabbitVCS I decided the domain and website needed to be migrated to my own servers.  A few weeks ago we transferred domain name ownership but kept the website hosting the same.  But today, we have moved all of the website, including the blog and wiki, to a new server under my control.  Hopefully, everything was migrated successfully.  But if you find any weirdness or issues, just let us know and we’ll try to resolve the problem.

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.

I am happy to announce that version 0.2.0 of the thunarx-python bindings have been released and are available for download.  The big news (and the only news) is that they can now run on any version of Thunar, all the way back to 0.4.0, so you don’t need to very latest release (v1.1.0) any more.

I’m in the process of getting thunarx-python hosted on Xfce.org, but it is slow going.  I’ll update everyone when this does happen, though.

Get it here: thunarx-python-0.2.0.tar.gz

SHASUM: e5838c597612d90f262add39ceae56dc59ad798b
MD5SUM: 6b6555157888e7dd91a15732b4970642

Git Repository: http://github.com/adamplumb/thunarx-python
Bug Tracker: http://github.com/adamplumb/thunarx-python/issues

Getting RabbitVCS to run on Thunar required me to create python bindings for the Thunar Extension Framework, but that is done now and the thunarx-python bindings are a reality.  I’m in the process of getting the source code hosted on Xfce’s git repository.

With RabbitVCS running on Thunar, we’re a small step closer to one of our big goals, which is to become file manager agnostic.

You can read my post on our mailing list about my trials and tribulations getting this all to work, but RabbitVCS on Thunar is a mixed bag.  On the one hand, I was able to get sub-menus working without having to patch Thunar, but on the other hand, there will be no emblem support for the foreseeable future.  However, one thing that Thunar has that Nautilus does not is a get_dnd_actions call, which asks plugins for menu items for when the user drags and drops an item into a folder. I haven’t implemented it yet, but in the near future this will allow you to move files around in your SVN repository via drag ‘n drop in Thunar.  Also not implemented yet is a property page that reports file status and ownership, etc.  All of that will be ready for the v0.13 release.

For now, I leave you with a short video of RabbitVCS running Thunar.

Get thunarx-python here: http://github.com/adamplumb/thunarx-python.  I’ve made a release, and you can get that in the Downloads section in github.  Currently, the only way to install the Thunar extension for RabbitVCS is to check out the latest code from SVN and run the development install.  Instructions for installing a thunarx-python plugin is available in the thunarx-python README file.  If you’re willing to brave the install, I’d love to hear your feedback!

One of the final pieces of the puzzle for v0.13 is the repository browser, and I am quite happy with it.  Sure, I bailed on having a folder tree view, and there is no drap ‘n drop support for moving files around, but overall I think people will find it very useful when v0.13 is released.

Here is a quick ‘n dirty video I made showing some basic functionality.  Hopefully we’ll have an alpha or beta ready for v0.13 and more people can test the new stuff out.