I invite everyone to try out the pre-release 1.0.3 version(almost done, just need to work out a kink with the installer). It goes a long way towards fixing the annoying problem where statuses aren’t populated on projects that are in solution folders. The solution isn’t perfect, and we have a long-term plan for a better way of doing it, but it’s a huge improvement over the current (1.0.2) state of things.

Find it at our new host: http://ankhsvn.open.collab.net/servlets/ProjectDocumentList?folderID=199&expandFolder=199&folderID=0

Hosting for the AnkhSVN project has now moved to http://ankhsvn.open.collab.net/. openCollabNet is "the online community extension to CollabNet products and Subversion" and the move represents an official commitment by CollabNet (the original sponsor of Subversion) to the AnkhSVN project in the form of developer time and other resources.

The Subversion repository has also been moved, and the new repository URL is http://ankhsvn.open.collab.net/svn/ankhsvn/trunk. Unlike before, anonymous access is no longer available, but you can checkout the repository using the username "guest" and a blank password. You can also browse the repository using the web interface at http://ankhsvn.open.collab.net/source/browse/ankhsvn/

Following the announcement of the security vulnerability in pre-1.4.5 Subversion, I am pleased to announce the release of AnkhSVN 1.0.2. This release can be downloaded from http://ankhsvn.tigris.org/servlets/ProjectDocumentList?folderID=7315

This release links to Subversion 1.4.5, which fixes the security vulnerability described in http://cve.mitre.org/cgi-bin/cvename.cgi?name=2007-3846. There are no other changes from 1.0.1.

I’m happy to announce the release of AnkhSVN 1.0. The release can be downloaded from

http://ankhsvn.tigris.org/servlets/ProjectDocumentList?folderID=7315

This release was built against Subversion 1.4.2, Neon 0.25.5, openssl 0.9.8a and Berkeley DB 4.4.20

Changes from RC4(*):

• Work around a couple of AccessViolations that would be thrown from the VS object model in certain cases.
• Fix refreshing of projects and projectitems statuses after certain operations.
• Fix some spurious expansions of the solution explorer in certain cases.
• More icons from DamienG
• Workaround for the error SVN throws when deleting a missing-but-added file.

* Full changelog can be viewed at http://ankhsvn.com/AnkhWiki/Changelog.ashx

Lately, I’ve been receiving a number of Ankh error reports that had an AccessViolationException. This was particularly weird because you cannot get that exception from safe managed code. AccessViolationException is the exception you get when you try to access memory you’re not allowed to access, usually because you are dereferencing an invalid pointer. Since safe managed code does not expose raw pointers, it’s not an exception you usually see in .NET development.

As it turned out, the exception came from a property accessor on an object from the Visual Studio automation model, a Project object. This is a COM object exposed to .NET and is implemented by the implementor of a specific project type, such as a C# project or a C++ project. Being a COM object, it can, of course, be implemented in a non-managed language, usually C++, which I suspect is the case here.

That answered the question of why such an exception could be caught inside Ankh, but it did not answer why we were seeing it in this particular case. It took a while for me to be able to reproduce it, but one submitter of an error report finally gave me a reproducible recipe: he had clicked on a linker error message in the Visual Studio error list. Linker errors aren’t associated with a specific source file, so clicking it usually does you no good, but in this case, it was clear that Ankh was doing something in response to this clicking and in the process, triggering the exception.

All files opened in Visual Studio belong to a project. This holds true even if you open a file that’s not part of your current solution, or if you don’t have a solution open. In that case, Visual Studio has a special project called "Miscellaneous Items", into which all files not part of any other project are put. This project is usually not shown in the solution explorer, but you can enable it by checking the "Show Miscellaneous files in Solution Explorer" checkbox in Tools->Options->Environment->Documents.

This project is not always present; rather, VS will load this project when the first "miscellanous" file is opened and close it again when no such files remain. Ankh has code to detect when a project is loaded and unloaded, and when a project is unloaded, we hook up an event sink to handle the case where files are added to or removed from the project, so we can refresh the status icons in the solution explorer. However, when such an event is raised, we cannot perform the refresh right away, because for some weird reason, the object model for the items hasn’t been updated to account for the changes yet. What we chose to do here is to schedule a delayed refresh of the item in question; ie, perform a refresh after a specific amount of time after the event.

What happened in this case was this:

1. User clicked on the linker error in the error list.
2. This, for some reason, triggered Visual Studio to load the Misc. Items project.
3. Ankh then dutifully hooked itself up as an event sink for events on the Misc. Items project
4. Visual Studio would then trigger the "Item added" event for the Misc. Items project (I’m not sure what it actually added, and don’t think I’ll spend much time trying to investigate it).
5. Ankh would then schedule a delayed refresh of the project.
6. Visual Studio would then, probably because it suddenly realized there was nothing to show, unload the Misc Items project again.
7. Ankh would unhook itself as an event sink for the Misc Items project.
8. However, the delayed refresh would still fire after its given interval.
9. The refresh would then work against a Project object representing a project that was no longer loaded. Accessing its properties at this time triggers the AccessViolationException.

The above sequence is a little simplified – Visual Studio did actually fire several Item Added and Item Removed events before unloading the Misc Items project, but it illustrates the problem.

One unanswered question here is why the COM/.NET infrastructure allowed the Project object to become invalid when there was still a reference to it in the managed heap. We’ve had a similar problem with ProjectItem objects, but in that case we got a more informative exception stating "ProjectItem not available".

Oh well, now that I know what the problem is, I only have to find a solution

There was a user on our users mailing list that asked if there was a way to remove a file from an Ankh-managed project without having Ankh delete it. I was about to tell him to use "Exclude from project" when I realized I should at least test it first (it’s not a feature I use a lot). I was pretty shocked to see that we do in fact delete files when Exclude From Project is invoked (if they are versioned – we don’t touch unversioned files).

I was even more shocked to see how VS behaves in this case:  The API we work against allows handling of delete (as well as rename and add) by implementing a certain interface. This interface has two sets of methods, OnQueryRemove* and OnAfterRemove* (with * being either Files or Directories). Normally, VS will first call OnQueryRemove*, where we have the option of cancelling the delete, and if we don’t, call OnAfterRemove*.

In the case of "Exclude from project", OnQueryRemove* is not called.

However, OnAfterRemove* is called, passing in a flag of VSREMOVEFILEFLAGS_IsDirectoryBased, which is documented as "Deprecated. Do not use."

Gah.

In the time since RC3, it became obvious from the error reports we received that renames and deletes were very buggy. Deleting a file and then committing it would often result in an error message saying "ProjectItem not available". It was obvious that we could not release it as 1.0 as it was, and another release candidate would be necessary. We also received several reports of other problems that turned out to be rather critical to some people, or so trivial to fix that we considered it worth the risk.

It took some time to rework the handling of deletes and renames to avoid this error (it’s a very tricky problem, I might write about it some day), thus the long delay in producing RC4. However, it is now available at http://ankhsvn.tigris.org/servlets/ProjectDocumentList?folderID=7315.

Problems that have been fixed include:

• The very common "ProjectItem not available" error.
• Templates for performing merge and diff using TortoiseMerge no longer has quotes.
• Reporting Services (and other Business Intelligence projects) now work.
• New icons (from DamienG).
• Solution load timeout in VS 2005 is increased from ten seconds to fifteen minutes.
• Various embarrassing NullReferenceExceptions.
• New lines entered for the log message in the configuration dialog are now treated properly.
• Handle an edge-case which prevented deletes from working with F# projects.
• Work around a NotImplementedException thrown in certain cases by certain third party project types.
• Various bug fixes in the support for database projects.
• Message box now shown if one or more items could not be Locked (previously this information was shown only in the output pane, and easily missed).
• Avoid a weird race condition in the repository explorer which might throw an exception in certain edge cases.

I have now changed the Wiki software for the AnkhSVN wiki to the wiki engine everyone is blogging about, namely ScrewTurn. I was immediately impressed by just how slick ScrewTurn was; dead easy to install and configure.

I have imported all the history from the previous Flexwiki-based wiki, however, historical versions lack proper formatting.

Unlike the previous wiki, this one requires users to be signed up in order to edit pages. This should let us avoid the wiki spam that plagued the old wiki.

Of course, it’s still a bit lacking in content, but I’m sure this will pick up quickly – ScrewTurn is so much more fun to work with than FlexWiki.

Damien Guard, more known as DamienG, is a new committer on the AnkhSVN project. He’s done some very good work for us already on redesigning the command icon set, and we look forward to working with him on new features in the post-1.0 timeframe.

The new icons will be available in the upcoming RC4.