What’s taking so long? Part I
In the words of Jace Hall (when sitting across the table from George Broussard and Scott Miller of 3D Realms, developers of Duke Nukem Forever):
On behalf of all of the fans out there, who know and love you guys. I say this with the most love that anyone could possibly [ask the question]: what the fuck is taking so long?
Let me take a shot at answering that question, let’s begin with the background. Starting with this chart from Ohloh, which should give you a rough idea of the activity of this project (note that the Google Code project, which Ohloh analyzes, was only started recently, in June of 2008, while NautilusSvn was originally started somewhere late 2006).
The last actual release was made by Jason in July of 2008 and sported only a few minor changes, after that development pretty much died down. The pace started to pick up once again when Adam joined the project mid November. This eventually led to my decision that Christmas (the time of the year people normally celebrate with their family) was the ideal time to start hacking away on NautilusSvn. During that period a lot of changes to NautilusSvn were made, more so than probably over entire 2008.
First of all, the entire codebase was heavily refactored. This is not something we took lightly. Every step of the way has been extensively documented on the wiki, from the decisions regarding the directory layout and the coding style to the architecture and the actual implementation. One aspect we’ve paid a lot of attention to was to clearly separate autonomous components. With an eye to the future we’ve started abstracting away from the actual VCS implementation. By doing this we increase the re-usability of major components of the system, so that in the future it will be trivially easy to support a different VCS whether that be Bazaar, Monotone, Git or any other VCS. We’re not there yet, but we believe we’re well underway. We’ve made sure that this goal would not interfere with our support of Subversion.
Somewhat of a sore eye in the previous version (for those of you who remember the dreaded “Refresh status” button) the core functionality, status checking and emblem handling, has been significantly improved. We’ve worked around some of the Nautilus extension API limitations and now NautilusSvn will also keep directory emblems up-to-date. This was somewhat of a pet issue of mine and I’m happy to see my efforts have not gon to waste. It’s still not quite there yet in terms of robustness, but overall it’s pretty decent and should work properly in most cases.
Another major change was that we’ve switched from using wxWidgets to GTK+ as our widget toolkit. This also means we’ve switched from using XRC files to Glade XML to describe the user interface, combined with the excellent Glade Interface Designer this should make modifying the GUI much more comfortable. As loyal users lurking on these mailing lists know this change was set in motion by the latest addition to our team, Adam Plumb. I personally think he’s done a fantastic job with refactoring the GUI layer.
This should give you some idea of what’s been happening over the last few months. In Part II I’m actually going to answer the question posed above.
Hello,
I love this project, I really do.
However, something I’ve noticed with with the trunk version of it (which, against advice I actually used) is that it uses a lot of memory when you’ve traversed through more and more directories of svn projects.
Is that an issue you are aware of and will fix in future versions ?? :)
….
Hey Stephen, thanks for the kind words. I hope to delve into some of this in Part II of this post. To be honest I haven’t yet been paying any attention to NautilusSvn’s memory usage, I’ve been focused on another related aspect: making the extension usable from a performance aspect.
Having a quick peek at the process list indeed shows that NautilusSvn (especially service.py) is using up a ginormous amount of memory and this will probably have a negative impact performance wise (especially on systems with limited memory). If you create an issue I’ll make sure it gets put on the roadmap. This is definitely something we’ll have to work on.
From the top of my head there might be a few things impacting memory usage:
1) We store a reference to the NautilusVFSFile instance for every file Nautilus encounters. We could probably significantly limit the amount of references stored.
2) We recursively add watches using pyinotify for every working copy encountered.
3) We cache the results of svn status operations and some other stuff.
4) We attach emblems which might obviously do something.
5) We use PySVN to do SVN operations, which might play a part in some of this.
Ok then.
well, I’ll post that issue :)
Thankyou for this awesome project :)