Core:

• Bug #371, When double-clicking a Previous Message, only the most recent message would be returned
• Bug #375, Some VCS actions were not prepared to ask the user for authentication.  The result was an error.
• In the Repository Browser, double-clicking “..” does the correct thing again (goes to parent folder)
• Bug #371, Allow diffs of directories
• Bug #363, Prepend the file:// protocol to strings PySVN expects to be URLS
• Bug #331, Quote URLs when passing them to VCS functions
• Many other bug fixes

Nautilus Plugin:

• Bug #296, No longer forces the English language

Gedit Plugin:

• The v0.13.2.1 release broke the gedit plugin, but it is fixed again with this release.

Homepage:

http://www.rabbitvcs.org

Download RabbitVCS v0.13.3 at:

http://wiki.rabbitvcs.org/wiki/download

Note: Distribution packages and our PPA will be updated within a day or two.

Note2: Ubuntu 8.10 (Intrepid) users should be aware that Intrepid has reached end-of-life status and our PPA packages will no longer build for it.

Issue Tracker:

http://code.google.com/p/rabbitvcs/issues/list

A big thanks and a great job to everyone on the team and everyone who contributed to this release!

Adam

Also, here is some more good news.  After several months of grueling back and forth, Juan (Nushio), our resident Fedora packager, has gotten RabbitVCS included in the official repositories, so starting pretty soon you Fedora users will be able to install RabbitVCS directly through the official repositories.

Here is a bugfix summary:

Core:

• Fixed some locale issues
• Fixed some minor issues for folks running python 2.4
• Small change to follow Fedora packaging guidelines, we’ll be in the Fedora repositories now!
• Bug #344, ‘Failure to rename because “The new name field is required”‘
• Bug #363, ‘Can’t use repo browser without a working copy: “. is not a working copy”‘
• In the Repository Browser, save urls when the user manually changes location
• When the Repository Browser is opened as a dialog, the “Close” button is renamed to “Select”.
• Bug #367, ‘Activating file in repository browser does not open, but thinks it’s a directory’
• Bug #361, ‘On Merge dialog leaving empty revision field cause hangup’
• Bug #360, ‘clear authentication information does not work’
• Backported a fix from trunk that allows one to double-click on a  message from the PreviousMessages dialog to select it.
• Bug #349, ‘Log top context menu: Re-enable update to revision feature’
• Bug #345, ‘Edit Property Value Doesn’t Fill Window Vertically’
• Bug #356, ‘Gradual accumulation of unterminated python subprocesses’  Note: This may not be 100% fixed, but we got at least one of the main causes
• Don’t show the Loading dialog twice when getting a diff from the log dialog
• All dialogs should have the rabbitvcs icon in the window

Nautilus Plugin:

• Fixed problem where the extension would still do all the status checking work even if both emblems and attributes (columns) were disabled.

Gedit Plugin:

• Bug #341, ‘Gedit plugin should be full menu rather than a part of “tools”‘
• Fixed some issues with older version of Gedit (r2425)
• Bug #325, ‘Make sure a window exists before updating it.’

Homepage:
http://www.rabbitvcs.org

Download RabbitVCS v0.13.2 at:
http://wiki.rabbitvcs.org/wiki/download

Note: Distribution packages and our PPA will be updated within a day or two.

Issue Tracker:
http://code.google.com/p/rabbitvcs/issues/list

A big thanks and a great job to everyone on the team and everyone who
contributed to this release!

Adam

I’ve wanted to write something about our performance problems for a while now. It’s a long standing issue, and something that is a real showstopper for some users. I’ve written this for two reasons: firstly, to tell our users why we haven’t “just fixed it” yet; secondly, so that other/future developers can get an idea of the WHY of the architecture and not just the HOW.

One of the oldest issues on the RabbitVCS issue tracker is issue number 4 — “Inadequate (sub-par) performance.” Hurtful, hurtful words, but ultimately true. The basic problem is that for small working copies, our extension works great. Once you get above about 50,000 items though, things really…

…Slow

…Down.

When you try to open up a folder with many version controlled children, Nautilus locks up. It is completely unrepsonsive until almost all the emblems are populated and — as much as I hate to say it — this renders RabbitVCS a little bit useless. Basically, we’re taking the I out of GUI.

Worst of all, it makes our “clever play on the word Tortoise” into a terrible, terrible irony.

What Performance Problems?

One of the first things  to understand is that performance is not actually the issue here. This may sound a little strange, but think about it: when our users say they want better performance, what they really seem to mean is that they want Nautilus to stay responsive. To put it another way, given the choice between:

1. Entering a versioned directory and waiting 1 minute for all the emblems to display correctly BUT have Nautilus lock up for the whole time; and
2. Entering a versioned directory and waiting 1 minute 20 seconds for all the emblems to display, but still being able to use Nautilus

…most users really seem to want (2), even though techincally (1) is the “better performance” option. Of course, if it were 20 minutes instead of one then yes, we’d have a problem. But that’s not what we’re experiencing at all. Status checks take the same amount of time, no matter what we do, no matter what language we use, no matter what the phase of the moon is. The call to vsc_client.status(path) will always always be our performance floor.

Now this might seem like minor semantic bickering — performance, responsiveness, who cares what you call it? But how you state a problem has a huge influence on how you deal with it (and how patient people are with your efforts…). Calling it a performance problem immediately implies a certain kind of solution, and causes well-meaning users to suggest things like JIT compilers and optimisers (bah), or rewriting in C (go on then). But if you stop obsessing over performance for five seconds, the solution becomes a little clearer. As Bruce and Jason (Field) realised, as soon as a Nautilus extension becomes non-trivial you need to start looking at how to do things asynchronously.

The simple story is:

1. Nautilus calls all of its Python extensions. They are all called in the same thread, and no other threading is permitted.
2. The Python extensions do their thing and return.
3. Nautilus displays the results.

So if step #2 takes minutes to complete, Nautilus is frozen waiting for a function call to return. That’s our problem.

Doing things in the background isn’t all that trivial though. For example, some users have suggested using threads to do things asynchronously. But threading is not permitted in Nautilus Python extensions, and so either the module will hang or just fail to run (depending on the direction of the local magnetic field). The next logical step is to use a separate process for the heavy lifting, so we have something like:

1. Nautilus calls all of its Python extensions.
2. The RabbitVCS extension calls a status checker service running in the background.
3. The status cache service should return immediately with either the real status or some indication that it will calculate the status (those cute little clock emblems).
4. The status is calculated.
5. The background service tells our extension when the status is calculated.
6. The extension tells Nautilus to invalidate the information for that path. This triggers another check, but now we have the status!
7. Profit.

This is what we’ve achieved so far for doing the emblems. We use DBUS to communicate with a background service that is automatically started on demand — we could have simple used a self-contained subprocess, but a DBUS service means that the other parts of RabbitVCS can access it too.

Diversions

The transition to DBUS was not as easy as it sounds. When we first moved things out to a DBUS controlled “subprocess,” we didn’t notice any improvement. This was because the Subversion bindings we use also prevent threading, and we were trying to intersperse status checks with status requests. This lead to me implementing a hideously complicated system of another layer of subprocesses to solve this. Really, we should have been using DBUS’ in-built asynchronous calling system to simplify things, which I finally got around to figuring out last week.

Another upshot of all this was what I learned about profiling. One of the most frustrating things for me was just how difficult it was to get a decent picture of what was taking so long in the first place. Profiling (in Python or otherwise) is an arcane art — unless you have a single process with a single thread, you’re going to get some mysterious results. The things that cause the most problems are thread synchronisation mechanisms, and if you’re lucky they’ll show up as huuuuuuge blocks of time spent waiting on a locking function. If you’re unlucky, you might as well throw darts at a stack trace. (Protip: print it out first.)

This isn’t a fundamental flaw with Python. But I was frustrated because the Python profiling tools aren’t designed to work on individual sections of the code. The most infuriating comment from #python regarding this was “which part of all this is cProfile.run(‘foo()’) ?” It’s a freaking embedded module inside a C extension API, not a shell script! Eventually I found a way to get a return value from cProfile so that I can profile the functions that Nautilus calls under normal use. (Of course, the good thing about subjecting yourself to #python is that the inhabitants do help you live up to the general Python philosophy of “if it seems harder than it should be, you’re doing it wrong, or possibly you’re an idiot with unsalvageable code; but let’s work on the other thing first.” I should have used DBUS properly from the start, and I should have remembered that it’s very rare for Python/C bindings to allow threading.)

So Close…

We’re now at the point where status emblems have almost no noticeable impact on Nautilus’ behaviour. Fantastic! So if we open up a test repository (in my case, sections 0-9 and A-D of the official Debian repository), Nautilus should just sit back and relax while waiting for everything to haaaaaappeeeeeeeeeoh the humanity it’s still freaking slow.

Here’s the problem: I forgot about the menus. Whenever Nautilus enters a new directory, it requests the menu items for the directory (“get_background_items”). This requires a status check, which yes indeed has to happen in the extension code. Nuts.

So why don’t we just do the same thing? Load up a menu that says “Please wait, loading…” and then use a callback to populate the menu? It’s a great idea, and the Nautilus extension API even has such a function: “nautilus_menu_provider_emit_items_updated_signal” which does exactly what it says on the box. Alas, the problem is with the Nautilus/Python bindings, which don’t allow us to use this method! The Nautilus/Python bindings have some real quirks in them, and it’s no trivial matter to simply pass Python objects and C interfaces around and expect things to work.

On the bright side, the Nautilus/Python bindings are now in the hands of Adam himself. It’s not always the case that cross-language bindings are in the hands of someone who uses them heavily enough to come up against constraints like this, so we’re at an advantage there. Adam has been hacking away to get the bindings to cover what we need, and while it’s not an easy task, it is certainly doable and should have some pretty good benefits even besides the menu signal. For example, once the proper Nautilus “update_file_info” callbacks are available, we can clean up a lot of hacky code and workarounds in the extension (possibly fixing a mysterious memory leak too).

I don’t want to promise anything too soon, but I do want to emphasise the fact that we are working on it, with an actual plan and everything! Keep your eye on issue #4, and if you’re a developer (or feeling brave), there will be a related branch in the repository soon. When we’ve got the code sufficiently functional, we’ll also release some packages for testing. So if you’re one of our users who has had to drop RabbitVCS because of performance problems, please hang in there — we are working on it, and it won’t be long now before we’ll be asking for all the real-world testing we can get.

Remember:

• you still need to install the core and an appropriate extension, eg. rabbitvcs-core and rabbitvcs-nautilus for the Nautilus extension.
• Nautilus users should restart Nautilus or log out and back in for the new extension to be loaded

If there are any problems at all, please send an email to the general discussion list or file an issue with the Google Code issue tracker.

What Took So Long?

The dedicated amongst you may have noticed that I took an entire week getting this packaged and released. Well, the problem was that with 0.13, we decided to split out our upstream tarball to make it easier for users to install only what they need. However, we soon realised that:

1. 99% of the tarball was taken up by the core, and
2. we never really change the core or extensions independently anyway, and
3. it’s a bloody pain

…so there wasn’t really any great gain to be had from that. In 0.13.1 we changed back to having a single “upstream” tarball, but still wanted to split out the various extensions and it was this detail that took me a while to figure out. From now on the tarball and the packages should be released at the same time.

RabbitVCS now in Debian

In other news, RabbitVCS has been accepted into the official Debian distribution. Debian users have the choice of using our PPA (I recommend following Lucid if you do), or simply waiting the extra 10 days for it to trickle into the testing distro (unless you use Sid, of course). One upshot of this is that it’s likely it will now make its way into the official Ubuntu repos too. Both of these events will make it much easier for new users of Debian and Ubuntu to find RabbitVCS.

As an aside, getting RabbitVCS into Debian was the reason I first got involved with this project in the first place, so it’s nice for me that it’s finally happened :)

I’m working on the debs too :)

Changes in RabbitVCS:

• Fixed the merge tool so it actually works
• Fixed the Create Patch dialog so it actually works
• Jason’s awesome new property editor!
• Removed help item from context menus
• Show the revision after a commit
• Mask the password in the Cert Authentication dialog
• Commits are now done non-recursively, so child files will not be committed if not checked.
• Many other bugfixes

Changes in RabbitVCS-nautilus:

• Fixed bug where clock emblem is shown forever

Changes in RabbitVCS-thunar:

• Menu item icons in thunar (<= 1.01) will now show up

Changes in RabbitVCS-nautilusold:

• Multiple fixes to get extension working in CentOS and older distros
• Added the Repository Browser menu item

Changes in RabbitVCS-gedit:

• Fix exception when context menu is activated
• Fix bug where dialogs don’t show up

Homepage:
http://www.rabbitvcs.org

Download RabbitVCS v0.13.1 at:
http://wiki.rabbitvcs.org/wiki/download

Note: We are releasing a single tarball archive now, instead of a core tarball and one for each client.  This should allow for simpler packaging and installation.

Note2: Distribution packages and our PPA will be updated within a day or two.

Issue Tracker:
http://code.google.com/p/rabbitvcs/issues/list

A big thanks and a great job to everyone on the team and everyone who contributed to this release!

Adam

This was actually fixed in the recently released nautilus-python 0.6 series, but existing distributions will generally not upgrade to major new releases (0.5 to 0.6), so the fix would only apply to new distribution releases.  Fortunately, there has just been a new nautilus-python release in the 0.5 series (0.5.2) which fixes this bug and a few others, and I believe Fedora will upgrade to it, making it available for all users.

Once the nautilus-python Fedora package is upgraded, we will release a 64 bit RPM for RabbitVCS.

Changes in RabbitVCS since v0.13 beta:

• (r2240) Fixed exception in Gedit client after activation
• (r2241) Checkout should be more flexible with the arguments it accepts
• (r2242) Make sure dialog responses line up with expectations
• (r2260) A different signal is required for gtk submenus
• (2261) Applied patch from sipych to fix multi-byte char sequences in the log dialog
• Some code cleanup and miscellaneous

Changes in RabbitVCS since v0.12:

• Improved context menus and selection functionality in most dialogs
• Massive overhaul in generating context menus
• Added a “Changes” dialog to view changes between revisions
• Added a “Check for Modifications” dialog to check for remote changes
• Added a repository browser
• All text views will provide a spell checker (if gtk.spell is installed)
• All tree views for files will show icons next to the file name
• Improved Diff/Compare functionality
• Modified the Properties dialog to allow editing revision properties
• Added functionality to the Annotate dialog to export to a file
• Countless bug-fixes and small improvements

Changes in RabbitVCS-Nautilus since v0.12:

• Improved status checking and emblem support, should be much faster now
• Added a Property Page

Changes in RabbitVCS-CLI since v0.12:

• Improved the handling of arguments.  Type “rabbitvcs -h” to get help or “rabbitvcs <module> -h” to get help.

Addition of RabbitVCS-Thunar:

• Adds the RabbitVCS context menu and a property page to the Thunar file manager.  This requires the new thunarx-python bindings, which are available from our downloads section.

Addition of RabbitVCS-Gedit:

• Adds the RabbitVCS menu to the main menubar and adds menu items to each source views’ context menus.

Addition of RabbitVCS-NautilusOld:

• Provides an extension that is compatible with older versions of Nautilus (< 2.22).

Homepage:
http://www.rabbitvcs.org

Download RabbitVCS v0.13 at:
http://wiki.rabbitvcs.org/wiki/download

Note: You will have to download the rabbitvcs core files (rabbitvcs-core-0.13.tar.gz) as well as the front-end-specific tarball (i.e. rabbitvcs-nautilus-0.13.tar.gz).

Note 2: Our Ubuntu packages no longer support Hardy (8.04), so users should either upgrade or use the tarballs for installation.

As this is a beta release, you should expect bugs and other issues to crop up, not only with the program, but also with our new packaging system which separates our front-ends (extensions) from the core.  We expect to have distribution-specific packages ready this weekend, but you can start testing with the tarballs that have been released.

Changes in RabbitVCS since v0.12:

• Improved context menus and selection functionality in most dialogs
• Massive overhaul in generating context menus
• Added a “Changes” dialog to view changes between revisions
• Added a “Check for Modifications” dialog to check for remote changes
• Added a repository browser
• All text views will provide a spell checker (if gtk.spell is installed)
• All tree views for files will show icons next to the file name
• Improved Diff/Compare functionality
• Modified the Properties dialog to allow editing revision properties
• Added functionality to the Annotate dialog to export to a file
• Countless bug-fixes and small improvements

Changes in RabbitVCS-Nautilus since v0.12:

• Improved status checking and emblem support, should be much faster now
• Added a Property Page

Changes in RabbitVCS-CLI since v0.12:

• Improved the handling of arguments.  Type “rabbitvcs -h” to get help or “rabbitvcs <module> -h” to get help.

Addition of RabbitVCS-Thunar:

• Adds the RabbitVCS context menu and a property page to the Thunar file manager.  This requires the new thunarx-python bindings, which are available from our downloads section.

Addition of RabbitVCS-Gedit:

• Adds the RabbitVCS menu to the main menubar and adds menu items to each source views’ context menus.

Addition of RabbitVCS-NautilusOld:

• Provides an extension that is compatible with older versions of Nautilus (< 2.22).

Homepage:
http://www.rabbitvcs.org

Download RabbitVCS v0.13 Beta at:
http://wiki.rabbitvcs.org/wiki/download/beta

Update: We have Ubuntu/Debian packages available for the beta now in our downloads section.

Issue Tracker:
http://code.google.com/p/rabbitvcs/issues/list

Big thanks and a great job to everyone on the team and everyone who contributed to this beta release!

Adam Plumb
The RabbitVCS Team