RabbitVCS

For me, and I think for a lot of other people, one of the key missing pieces of functionality for RabbitVCS v0.12 is robust support for comparing files, folders, and revisions; so this is the first thing I started working on for v0.13.  So far, I’ve updated the log viewer and created a new dialog devoted to comparisons, but I’ll be improving context menu functionality throughout all dialogs.  Here is a video preview of the new log view functionality and the compare dialog.

Good news!

We’ve overhauled the architecture of the NautilusSVN status checker and things are looking better for usability and performance.  To try to solve our performance problems, we basically cheated (bear with me here…)

read more »

Yesterday I spent all day working on the reincarnation of the status monitor. Basically what this means is that I started from scratch, worked out the ideal architecture based on past experience and starting reassembling the extension by copying code from trunk and the old status monitor back in (reviewing it and improving it wherever needed).

I’m far from done, for example I haven’t yet started on implementing the ideas for the auto-updating status tree, but it’s starting to look pretty descent. Besides obviously removing a lot of crud by refactoring, here’s what major things have been done so far:

• Reimplemented the status monitor, but this time using gio.GFileMonitor. Not only does this mean that NautilusSvn will run on all systems that support GFileMonitor (e.g. *BSD) but the resulting code is even prettier!
• Moved to using anyvc for the VCS Abstraction Layer. This library was originally developed for usage with PIDA, a Python IDE. This means that there’s now free emblem handling for at least Subversion, Bazaar, Git, Monotone, Mercurial, Darcs. So no matter what VCS you use you will always see pretty emblems!

What’s still missing:

• The context menu. I still have to port this to using anyvc.
• The entire GUI Layer. This also has to be ported.
• The status tree implementation as discussed on the Architecture wiki page.

If you’re interested you can take a look at the resulting code. Once I get this branch into shape I’ll start making development snapshots so everybody can play around with it.

In other news thanks to Vadim Peretokin I figured out what was causing the Launchpad buildbot to fail on building NautilusSvn, turns out I was missing a few build-dependencies that were required because of commands called from the Python distutils script (pkg-config and gtk-update-icon-cache). Thanks Vadim!

Based on the results so far from the performance poll with a sample of 130 users it seems 38% of NautilusSvn users are not satisfied with the current performance of the extension, while about 43% of the users could be considered satisfied. 19% rated performance as acceptable but it’s a thin line both ways so I won’t count them in either camp. There are very few people that flat out refuse to consider NautilusSvn because of this issue, if I had to take a guess I’d say some 11% ;-)

If I had to place a wager I would bet that most people don’t mind if NautilusSVN takes a while to determine the status for entire working copies (to a certain extent), as long as it doesn’t overheat their CPU, doesn’t consume too much memory and most importantly doesn’t hang Nautilus. If anybody disagrees with this please leave a comment.

However, judging by some of the comments it seems that some people just have extremely large working copies or tend to collect a lot of extremely large working copies in a single project directory. Based on some tests with timing the PySVN status method and the command-line Subversion client I would have to say that there’s really not a lot that can be improved with regards to actual performance. I’m sorry to have to say it, but that’s just the way it is.

Allow me to elaborate.

First, note that on average initial status checks take about 10x longer than consecutive ones. For example, the initial check for the entire TortoiseSVN working copy takes 8309.0079 milliseconds, consecutive ones take 865.9279 milliseconds. That’s 8 seconds compared to 0.8 seconds, I think everybody agrees with me that that’s quite a difference. However, as I see it there’s simply no way to speed up that initial status check. So, say you have 15 working copies the size of TortoiseSVN organized in a single directory, upon entering that directory it would take NautilusSvn some 2 minutes to just figure out the statuses.

Also note that if we want to properly keep working copy and directory emblems up-to-date we’ll also have to recursively register watches on each working copy, initially registering watches using inotify in the case of the TortoiseSVN working copy takes quite a few seconds (I didn’t time it).

There’s still room left to make NautilusSvn more efficient and perhaps a bit more snappy here and there. Especially with regards to the status logic there are still improvements that can be made. Also the implementation of a proper cache will certainly help in making consecutive status checks even faster. But none of this will result in substantial improvements in the area of initial status checks.

So if there isn’t a way to substantially improve performance with regards to initial status checks what can we do? What I know we can do is create the illusion of performance or possibly degrade some functionality. Here’s a few things that come to mind:

• Pre-loading working copies. Do the initial status checks when the user isn’t looking. It’s probably a good idea to not do this immediately after booting. We would also have to make sure the computer is not on battery power.
• Allow the user to configure to disable NautilusSvn for certain directories.
• Do some scheduling tricks and progressively check parts of a working copy. This will also help prevent 100% CPU usage issues for a considerable duration of time (leading to overheating).
• Executing the status checks asynchronously

However, let me point out that doing everything asynchronously (i.e. in the background) will only obscure performance issues. Sure, Nautilus wouldn’t hang anymore but NautilusSvn will still be hacking away in the background (possibly causing your CPU temperature to rise to unacceptable levels). Especially when developing I find Nautilus hanging a very useful indicator on whether or not progress is being made.

In the end, irrelevant of the performance issues, what I’m most interested in is having an elegant, flexible, maintainable and robust codebase.

Any thoughts?

P.S.

I hope to be posting more of these type of blog entries, that is if people are interested in hearing me talk about this. :-) Now, back to pointless, incessant barking.

I know that compared to the early months of 2009 it has been a little quiet around the project lately. But don’t worry, we’re not dead! It’s just that Adam is getting married this summer and quite understandably pre-occupied with planning the wedding. I myself simply haven’t had the energy lately to work on the project, there’s some tough issues to solve and I haven’t had any brilliant ideas.

I’d like to take a moment to thank everybody that has contributed to the project so far, from the people providing patches and translations to the people participating in the discussions on the mailing list and on this blog. Note that even though I haven’t yet participated in the discussions on this blog I always read the comments that everybody posts.

Since the 0.12 beta release in March there have already been over 3000 downloads and the project has been mentioned in well over 60 separate sites/blogs/forum threads etc. (yes I’ve actually been keeping track of this!). The reaction is overwhelmingly positive as also indicated from several very thoughtful messages to the mailing list ([1] and [2]).

For me personally my involvement in this project has been an amazing experience, one that I would like to continue. I consider my responsibility as a project manager to make the barrier towards contribution as low as possible and motivate the community to participate. There’s still a lot that needs to be done to make NautilusSvn more easy for us and other people to develop on and that’s going to be one of my major focus points

The coming months I will be focusing on refactoring NautilusSvn to make several improvements to the overall design which will lead to an overall better application but also improvements in performance and hopefully memory consumption. I’ll be documenting my progress on the Architecture and Code Sprint wiki pages.

Once actual work gets underway snapshots will be regurarly released. In the meantime people will have to make do with the current beta release.

Note that I’m still looking for help in getting the PPA set-up and ready to go for distributing NautilusSvn. The Launchpad buildbot is currently unable to build any packages for the sources I upload and I have not been able to understand from the logs yet precisely what the issue is. Contact me over the mailing list if you think you can help.

UPDATE: Thanks to Vadim Peretokin I figured out what was causing the Launchpad buildbot to fail on building NautilusSvn, turns out I was missing a few build-dependencies that were required because of commands called from the Python distutils script (pkg-config and gtk-update-icon-cache). Thanks Vadim!

Please don’t hessitate to drop by for a talk in our IRC channel #nautilussvn @ Freenode (chat.freenode.net)!

Thanks!

I’d like to introduce myself. My name is Plumb…Adam Plumb. I live in Northampton, Massachusetts, USA, am in my twenties, and work from home as a web developer. I recently created an online boggle clone game called Serpentine, which people have been having a lot of fun with. I’ve been a linux user for a few years now, and have strongly missed having a subversion extension for my file managers (I used TortoiseSVN in Windows). Queue to this autumn when I started learning the Python language and found out about the nautilus-python bindings. I decided to make a TortoiseSVN clone for Nautilus, and started working on my idea until I found the NautilusSvn project and joined forces with Bruce. Together, we decided to do a complete rewrite of NautilusSvn and transform it from a collection of scripts to a robust, well-engineered application.

We’ve been hard at work on the NautilusSvn v0.12 rewrite for well over two months now, and are getting quite close to an alpha (“feature-complete but expect breakage”) milestone. At this point, we’re only waiting for Bruce to finish up his status checking code before we can release an alpha snapshot and ask people to start testing. Indeed, Bruce has been very busy with work and “real life” lately, but the positive side to that is the “delay” has given me an opportunity to continue to polish the UI (which needs to be a bit more robust).

Once we release an alpha snapshot (hopefully within the next couple weeks), we’ll get to work fixing bugs and refactoring in order to get a really solid v0.12 final release.