[unknown button type]

Known Issues

Obviously all bugs in our issue tracker are known issues, however here are some of the really important ones.

No Nautilus context menu icons

If you notice that the RabbitVCS menu icons are not showing up, this is actually the result of a decision by GNOME upstream to cease displaying icons in menus by default.

You can change this behaviour by right clicking on the desktop, then select “Change Desktop Background” » Interface » Show Icons in Menus

…or try running:

gconftool-2 –type bool –set /desktop/gnome/interface/menus_have_icons true

(You can also use Applications > System Tools > Configuration editor, browse to that key and check the box.)

See the RabbitVCS bug report and the original GNOME bug report for more details.

Failure to install with GDebi

Ubuntu Karmic users: please note that gdebi bug #393381 will cause manual installation to fail with:

dpkg: unable to read filedescriptor flags for <package status and descriptor>: bad file descriptor

This can be fixed by upgrading python-vte. If you can't do that, use the PPA.

The main context menu will appear with items in incorrect places

This is a bug in Nautilus (we think) and so far we haven’t found a workaround. If you get this, most of the time you can click away (in the Nautilus background) and then click back on the original item, and this will give you a correct menu. For more information see Issue #96

No support for mounted locations

RabbitVCS currently does not support mounted locations, e.g. when you access a directory over SFTP, SMB, FTP or some other protocol with a custom URI scheme. For more information see Issue #158.

This problem only occurs on older versions of Nautilus e.g. 2.22.2 (or everything ⇐ 2.24.1). Nautilus 2.22.2 is the version included with Ubuntu 8.04. The RabbitVCS menu item is not shown as a submenu when clicking on the file manager background or inside the File menu, however it does show up in the Edit menu and in the context menu for a selection.

RabbitVCS suddenly doesn't show emblems anymore, just the clock icon

In some cases it can take a while for a status check to be processed, but if you're sure something is wrong then it's likely the daemon has either crashed or hung. You'll have to make sure it's gone and restart Nautilus using:

pgrep -f service.py | xargs kill; nautilus -q; nautilus

User interface dialogs lock/hang up

The problem here is most likely that you have GNOME Accessibility features enabled. If you do not require these features you can disable them in System → Preferences → Assistive Technologies. For more information see Issue #94.

Limitations of the current status checker

There are three situations where we currently can’t keep emblems up-to-date:

When any file that isn't visible is modified

  • An example: if you’re in /foo and the file /foo/bar/baz is modified (e.g. edited and saved) the status for /foo and /foo/bar will be incorrect. Nautilus doesn’t inform us about these modifications (which makes sense for normal extensions). We have been working on a new status monitor so in the future we will be able to do this.

Adding items

  • Another example: if you’re in /foo and /foo/bar is “normal” and you add /foo/bar/baz by selecting RabbitVCS → Add from the context menu of /foo the statuses for /foo and /foo/bar willbe incorrect. We’re only rechecking the paths you originally selected and any item you saw that was either “added”, “deleted”, “replaced”, “modified”, “missing”, “unversioned”, or “incomplete”. There might be something I can think up here that might not impact performance all too badly.

Using the command-line svn client

  • We've currently implemented something similar to a callback system for any functions called from the context menu. Once a function is done, we'll recheck the status for the relevant items. This obviously doesn't work when one uses the command-line client. With the exception of svn revert we currently cannot keep emblems up-to-date when you use the command-line client, you'll have to use F5 to refresh. Again, the new status monitor will eliminate this problem.

We're planning to implement a new status monitor to get rid of these limitations in release 0.13.

Note that in all cases, the correct emblems should appear if you manually refresh the Nautilus window (eg. by hitting F5).

RabbitVCS won't run in some 64 bit environments

Some distributions, such as 64 bit Fedora, put 64 bit libraries in the /usr/lib64 directory, whereas nautilus-python (the program that lets us extend nautilus) assumes all libraries are in the /usr/lib directory. This is a nautilus-python bug. The current workaround is to create a symlink: ln -s /usr/lib64/libpython2.6.so /usr/lib/libpython2.6.so