RabbitVCS

Adam and I have come to the conclusion that the new status monitor that is needed to keep emblems up-to-date can not be included in the upcoming release, it’s simply not yet ready for production usage (among other things see Issues 4, 8, 89 and 90).

As we don’t see how we can significantly improve things with a few tweaks here or there we’ve decided to instead work on removing the status monitor completely for the time being and only have a status checker (similar to the situation in v0.11, but more elegant). We’ll also get the rest of the code up to production quality.

Regretfully, without the new status monitor we are not able to detect changes to files that are not directly visible in the Nautilus window. So if you’re in the directory /foo but the file /foo/bar/baz (baz) is added the emblems for foo and bar will not change to modified (assuming the status before was normal). This also means you cannot use the command-line svn client and expect emblems to be kept up-to-date.

UPDATE: actually after implementing the new status checker it turns out the above isn’t entirely correct. If you do alll VCS actions through NautilusSvn and don’t use the command-line all emblems will remain up-to-date. There seem to be two situations where we can’t keep emblems up-to-date:

• If you’re in /foo and /foo/bar/baz is modified the status for /foo and /foo/bar will be incorrect. Nautilus doesn’t inform us about these modifications (which makes sense for normal extensions). The new status monitor is required to be able to do this.
• If you’re in /foo and /foo/bar is “normal” and you add /foo/bar/baz by selecting NautilusSvn -> Add from the context menu of /foo. 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.

Hopefully we will be able to get the status monitor ready for v0.13.

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.

For the past week, we’ve been working on releasing an actual beta package for NautilusSvn.  Alas, there are still some glitches and bugs we’re trying to work out, which is slowing down the release.  Hopefully we will have these worked out soon and we can charge forth into the next stage of development.  Stay tuned!

After initially writing off localization capabilities for v0.12, preferring to wait until v0.13 for that, I later changed my mind and spent some time figuring out how to do it, implementing it, and writing up the documentation for others.

Translating NautilusSvn is a fairly simple process.  We provide a template file that has the English text from our program and a space for the translated text that you will write.  The template file is located at branches/v0.12/nautilussvn/po/NautilusSvn.pot in our svn repository.  In order to start your own translation, you will first need to install the gettext and intltool utilities, which you can generally get from your linux distribution.  You may also want to install poedit, which is a popular and very useful GUI translation tool.

Once you’ve got your environment set up correctly, you can generate the actual translation file you’ll be using.  First, figure out which language and locale you’ll be translating NautilusSvn to.  For example,  en_US is English/United States (the default), and en_CA is English/Canada.  For a list of locale codes, go here.  And for a list of country codes, go here.

Once you’ve figured out your language and locale, you can begin.  For the purposes of this tutorial, I will set up a translation for en_CA (Canadian English).

$ cd /path/to/nautilussvn
$ msginit –input=po/NautilusSvn.pot –locale=en_CA
$ mv en_CA.po po/en_CA.po

The translation file you want to modifiy is now in the po folder, and you can begin your translation!  You may use poedit or another GUI tool or edit the text file by hand.  Once you’ve finished, type:

$ mkdir -p locale/en_CA/LC_MESSAGES
$ msgfmt –output-file=locale/en_CA/LC_MESSAGES/NautilusSvn.mo po/en_CA.po

And you’re done!  If you want NautilusSvn to use your changes, you’ll want to export your language (en_CA) to the LANGUAGE environment variable and restart nautilus and NautilusSvn:

$ export LANGUAGE=en_CA
$ nautilus –q; pgrep –f service.py | xargs kill; nautilus —no–desktop; pgrep –f service.py | xargs kill

When your translation is all finished, open a new issue in our Issue Tracker and attach the NautilusSvn.mo and .po files that you created.  We will immediately update our development trunk, and it will be included in the next official release.

Launchpad Translations

We’re currently trying to get our project set up on Launchpad in order to coordinate translations from there, but it isn’t quite set up yet.  We will make an announcement on this development blog and also our mailing list when it is completely set up.

String Freeze

NautilusSvn is currently in the “ALPHA” stage of release and we have not yet reached “string freeze” (the point at which we will not change the English strings in the program).  Strings won’t be frozen until we reach the “BETA” release, which is scheduled to happen next week (but it may not if there is a delay).  You can start translating now if you’d like, but please be aware of any changes that happen to the NautilusSvn.pot template file until the beta.

Happy Translating!

This is my first post highlighting NautilusSvn’s many UI windows and dialogs.  First in line is the frequently used Commit window.

The Commit window provides an interface for committing or checking in modifications made to your working copy.   The first area of the window, “Commit to:”, shows you the repository you are working with.  The “Add Message” area allows you to add a log entry to your commit.  The Changed Files table shows all added, deleted, modified, missing, replaced, obstructed, or unversioned files.  Best of all, there is now a context menu that gives you the opportunity to View Diff, Open, Browse to, Delete, Add. Revert, or Ignore the file in question.

When you click the “Previous Messages” button, a dialog pops up with the past 30 messages you’ve written (changeable in settings).

When you click “OK”, the commit starts and the notification window pops up, giving you feedback and what is going on…

Happy committing!

At some point in the past few weeks I decided that I want to be able to access the v0.12 NautilusSvn UI elements from the command line. So I wrote a simple executable python script called “nautilussvn” which calls the UI element of your choice as well as passes through any other arguments you give it. I simply put a copy of the script in my PATH (mine is at /usr/local/bin/nautilussvn) and call it any time I want from the command line.

Here’s an example of what I’d do if I was in the base directory of some working copy and I wanted to commit the code with svn:

#$ svn commit -m "MESSAGE GOES HERE"

With the nautilussvn script, It’s just about as easy, and you get all the UI goodies you’ve come to love…

#$ nautilussvn commit

Or to specify a path:

#$ nautilussvn commit ~/Development/thiswc

If you want to see all the available modules, just enter “nautilussvn” and you’ll get something like the following:

#$ nautilussvn
usage: nautilussvn <module> [path1] [path2] …

Available Modules
——————
about, add, blame, checkout, cleanup, commit, create, delete, export,
ignore, import, lock, log, merge, properties, relocate, rename,
resolve, revert, settings, switch, unlock, update, updateto

I tend to use the command line quite a lot for work already, so this gives me access to some of the UI features I love (like working with files in the commit dialog) without the hassle of having to open up nautilus.

Just as Adam did I too would like to introduce myself. My name is Bruce van der Kooij and I was born and raised in The Netherlands, am in my early twenties, recently graduated and currently work as a technical consultant for a local IT company.

I’ve been involved in the NautilusSvn project for quite a while already, at least since Juli 2007. I was one of the major reasons Jason migrated the project to Google Code in June of 2008 (prior to that it was solely being distributed as a tarball through Jason’s personal website). However, up untill recently my contributions to the project consisted of a few minor patches here and there (one liners) and janitorial work (helping people on the mailing list, triaging bugs, updating the website etc.).

Largely thanks to Adam all that changed last Christmas. I felt that the time of the year people normally celebrate with their family was the ideal time to start hacking away on NautilusSvn. And hacking away I did. I worked some 8 days non-stop (8 to 16 hours a day) on implementing some major parts of the extension.

The core functionality, status checking and emblem handling was significantly improved. Though as Adam indicated there are still some kinks to work out. Another major feature was the implementation of submenus, an implementation I’m quite proud of myself.

In the process we have to work around several limitations in the Nautilus extension API (libnautilus-extension). One example of this is that the update_file_info function tells us about changes to items (directories and files) but not about items that aren’t visible in the current view, this is the major reason directory emblems are not kept up-to-date in v0.11 (and a manual refresh is required). We’ve worked around this particular issue by using inotify to keep track of modifications ourselves.

As Adam indicated in the previous post I’m currently working on finishing up the status checking code (mostly performance issues), I hope to do so somewhere in the coming days/weeks (but certainly not months ;-).

Hi everyone!

Welcome to the development blog for the NautilusSvn project.  Our project’s actual website is hosted on google code at http://code.google.com/p/nautilussvn.

What is NautilusSvn?
NautilusSvn is a Python extension for Nautilus which integrates a load of Subversion functionality into the GNOME Nautilus file manager, basically as a clone of the TortoiseSVN project on Windows.

What is the project’s current status?
The current “stable” version is v0.11, which provides a set of basic tools, including:

• Checkout
• Commit
• Revert
• Diff (using Meld or gvimdiff)
• Log Viewer
• Revision and SVN User as columns in Nautilus views
• Emblems to show file status (though buggy)
• SSL authentication (buggy)
• Username and password entry dialog
• Editing Properties

However, the next version, v0.12, is going to be a total rewrite, with some pretty awesome features and functionality.  Here is a list of what to expect for v0.12:

• Complete rewrite of extension and user interface layer.
• Improved status checking and emblem support. Manual status refresh no longer required.
• An entirely new context menu in Nautilus including submenus.
• New UIs: Add, Copy/Branch, Cleanup, Export, Import, Lock, Merge, Relocate, Revert, Rename, Settings, Switch, Unlock, Update-to-Revision.
• Updated UIs: Checkout, Commit, Popup Dialogs, Log, Notifications, Properties.

• Many UIs now have context menus.

• Working packages and installation instructions for major distros (Ubuntu, Fedora)

We’re getting really close to an alpha (“feature-complete but expect breakage”) milestone, with beta and final milestones coming soon afterwards.

Keep your eyes peeled here for more news, updates, and developments on the NautilusSvn project.