RabbitVCS

With the strings frozen for v0.12, I’ve uploaded the translation template file to our launchpad page, and it is now possible to translate NautilusSvn directly from launchpad!  Simply follow the above link and click the “Help translate” button.  You can find more detailed instructions here.  Once you’ve completed your translation, open a new issue on our project site to let us know about it.

We already have french and german translations in our first beta and hope more people will help out and translate for us.  Thanks!

Note that when you encounter a working copy for the first time during a session Nautilus will hang while NautilusSvn does an initial recursive status check, for extremely large working copies (think thousands of items) this can possibly take up to a few minutes. Consecutive status checks after the initial one should be much faster and in most cases a status check will not even be executed anymore (cache hits, < 1ms).

[poll id=”2″]

Thanks! Be sure to leave any comments you have in the commentary section below.

There were some packaging problems I felt warranted an update/rebuild. Here’s what got fixed:

• Updated version dependencies in control file so the package can be installed under Ubuntu 8.04. See Issue #100.
• Make sure that gtk-update-icon-cache is executed after install. See Issue #87.
• Have to prepend emblem- to all emblem files for them to be picked up by Nautilus <= 2.22.3. See Issue #87.

Looks like we still have to work out our version numbering scheme. :-)

Next, performance issues! \o/

That’s all folks.

Hi all,

It has been a longer wait than anticipated, but the first beta is finally here!  We have several goals in mind for this beta and future betas:

• Produce installable tarball packages of NautilusSvn
• Produce distribution-specific packages (deb and rpm packages)
• Maintain a stable/unchanging set of strings for translation purposes
• Get NautilusSvn in a state where it can be used by the general public every day

The wait has mostly been related to some last minute issues with the installable tarballs and packages.  Indeed, Bruce and I are still learning the release engineering trade, so you can probably expect us to fumble some more in the near future ;)  We’ve also been tinkering with the status monitor, amongst other things, trying to make them simpler and more reliable.

Whereas the ALPHA was simply a statement that we wanted people to start actively testing the NautilusSvn v0.12 branch, this beta is our first honest-to-goodness release.  We plan on releasing a few betas, until we are sure we’ve ironed out the kinks in the release process and in the program.

RELEASE SCHEDULE
——————————

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!