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

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.

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.

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

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.

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

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.

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

• 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.

• 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.

• 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).

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