Random thoughts about AnkhSVN, .NET, Powershell and other stuff: AnkhSVN

Ankh and AccessViolationExceptions

Sun, 12 Nov 2006 18:24:41 GMT

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:

User clicked on the linker error in the error list.
This, for some reason, triggered Visual Studio to load the Misc. Items project.
Ankh then dutifully hooked itself up as an event sink for events on the Misc. Items project
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).
Ankh would then schedule a delayed refresh of the project.
Visual Studio would then, probably because it suddenly realized there was nothing to show, unload the Misc Items project again.
Ankh would unhook itself as an event sink for the Misc Items project.
However, the delayed refresh would still fire after its given interval.
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 :-)

Ankh and Exclude From Project

Fri, 10 Nov 2006 21:09:59 GMT

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.

New wiki

Mon, 23 Oct 2006 17:48:40 GMT

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 new AnkhSVN committer

Thu, 12 Oct 2006 16:51:02 GMT

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.

Losing faith

Thu, 07 Sep 2006 20:56:39 GMT

(Also posted as a reply to a post on our mailing list, users@ankhsvn.hm.hm)

Gah. I'm starting to lose my faith in my fellow programmers. A little background:

Ankh uses a couple of hash tables to map EnvDTE.Project and EnvDTE.ProjectItem objects (these are from the VS automation model) representing projects and (doh) their project items to our internal objects representing the same artifacts. These hash tables are used extensively when gathering SVN resources to determine whether commands should be enabled and to provide input to the execution of said commands. In other words, when a command is invoked, the hash tables are queried for our internal objects corresponding to the currently selected ProjectItem or Project.

So, if this mechanism fails, commands won't be enabled in the first place, and if they were, they wouldn't execute correctly since no resources had been harvested.

And this mechanism will obviously fail if the hash codes retrieved from the Project and ProjectItem objects are different each time they are retrieved using GetHashCode().

I'll leave the rest of this horror story to the imagination of the reader. I will not reveal the particular type of project that is committing this atrocity; suffice it to say that the common name for it starts with an R and ends with -eport Server Project.

Oops

Wed, 16 Aug 2006 18:12:43 GMT

/me sighs.

Ok, I screwed up. Due to a braino and a particularly brain dead "feature" of our build script, the MSI wasn't built from the release branch. It was instead built from a short-lived branch I created to integrate our build process with Subversion 1.4. The released MSI is pretty close to what was supposed to have been released (which is of course why I didn't discover this ;-), but lacks some bug fixes made in the last day.

An updated MSI can be found at the same URL as the other one.

AnkhSVN 1.0 release candidate available

Tue, 15 Aug 2006 21:25:34 GMT

An AnkhSVN 1.0 release candidate is now available at http://ankhsvn.tigris.org/servlets/ProjectDocumentList?folderID=7315. This is linked to Subversion 1.4 rc4, Berkeley DB 4.4.20, OpenSSL 0.9.8a, Neon 0.25.5 and Zlib 1.2.3.

Note that any application linked to Subversion 1.4 (including the Ankh release candidate) will silently and irrevocably upgrade your working copies to a new working copy format. Use of such an application together with a pre-1.4 client will not work. The TortoiseSVN project makes a 1.4-compatible client available at http://tortoisesvn.net/downloads. 1.4-compatible versions of the svn binaries can be found with the AnkhSVN release candidate.

Also, the release candidate is linked to Berkeley DB 4.4. If you are using a local (file://) BDB repository with Ankh, it will need to be upgraded. Our general recommendation is to avoid the use of BDB for file:// access in favour of FSFS repositories.

Changes since 0.5.5:

Internal diff no longer shows duplicates
Fix a memory leak in the NSvn.Core.Pool class
Clicking the X in the commit dialog now performs a cancel, regardless of whether the most recent action was a cancel or not
NSvn exceptions are now serializable
Commit dialog now supports Ctrl-Enter for proceeding with a commit
Commit dialog text control now supports Ctrl-A to select the whole text
NSvn.Core.Client.Delete now supports the 'force' parameter... :-/
Status icons in the solution explorer are no longer overwritten by VSS ones
Configuration dialog has templates for the most common diff and merge tools
Individual project items can now be refreshed with the Ankh->Refresh command
The '?' status no longer propagates up the solution explorer treeview
New projects are now automatically SVN-added if they are versionable
Add Solution To Subversion Repository now warns the user if some projects are not under the solution root
New configuration dialog
Config file changes are picked up without having to restart VS
Fix for a memory leak in the solution explorer
Redesigned delete support
Support for the VS refresh button
Fix for a problem in which a premature solution explorer refresh after a folder add terminates the rename of the newly added folder and forces it to be named "NewFolder1".
We now call svn_utf_initialize so that iconv SOs don't have to be loaded for every SVN error message.
Workaround for Windows Workflow Foundations beta 2 bug
GDI handle leak plugged
All dialogs now invariably support standard Enter/Esc for OK/Cancel
Blame now works correctly on compound items
Use Visual Studio SDK for better VS integration
The commit dialog can now be suppressed with the Shift key, like other dialogs
Support for alternative names for the SVN administrative directory now uses the functionality offered by SVN itself
New "Working Copy Explorer" tool window
Better support for renames and moves
Redesigned VS integration to take advantage of the Visual Studio SDK
Better unicode support for log messages
Support for VS 2005 solution folders
Dialog tab order fixes
New installer using WiX instead of the VS.NET setup projects
Fix bug in which Ankh would refuse to load if VC++ wasn't installed
Prevent .svn dir from being autoadded
Support rename on folders in projects
Prevent Ankh from autoadding ignored files
Prevent the solution explorer from repainting itself while Ankh is scanning the tree, improving solution load performance
Running of SVN commands from the VS command line is now streamy
New command that lets user send a suggestion or error report without actually experiencing an error
Diff/Patch uses path relative to the solution directory
Better support for third party project types
Support commits on working copies created from multiple repositories
Commit dialog is now "pseudomodal", allowing the user to diff or view files using VS directly
Ankh no longer loads on command line builds that use /rebuild or /clean
Support for blame
Diff/patch between arbitrary revisions
Use the correct name for the Tools menu in non-english versions of VS
Support for log
Better support for file deletions
More intelligent status cache, improving performance (especially in pathological cases)
Support for VS 2005
Error reports contains the DTE version (and thus implicitly the version of VS)
Support for lock/unlock
New design for the repository explorer
Support for Enterprise Template projects
Support for database projects
Lots of tweaks, bug fixes and performance enhancements.

Ok, maybe not this weekend, then

Sun, 13 Aug 2006 20:26:51 GMT

I promised a release candidate this weekend, but it looks like that won’t happen. Integrating our build process with Subversion 1.4 and Neon 0.25 took a lot more effort than expected. We’re now probably looking at either Monday or Tuesday.

And we still haven’t quite decided on the version number…

Ankh, how do I number thee?

Thu, 10 Aug 2006 18:22:21 GMT

We’ve decided to go ahead and make a new Ankh release. A release candidate will come this weekend, and then a proper release will follow in a week if there are no major problems found. I’ve closed the last of the issues marked 0.6 in our issue tracker, so this seems like a good time to do it

One problem remains, though: what version number to give it? The obvious choice would be 0.6, since our last “official” release was 0.5.5. However, we’re getting sort of tired of the 0.6 marker by now, and we’re considering to maybe give it a version number of 0.7 or even higher. One person I talked to on IRC yesterday suggested 0.9 or even 1.0.

There are already 35 different snapshots all marked as 0.6.0.* around, and the idea is that giving it a higher version number might give a much clearer message that this is indeed a new version.

What do you think?

Is Ankh a dead project?

Tue, 08 Aug 2006 16:25:09 GMT

To avoid any potential confusion, I’ll start out this post by answering the question above: heck no!

I’m posting this because it is starting to dawn on me that there seems to be a pretty widespread perception that we are indeed a dead project. In particular, this thread on the Subversion users mailing list made this pretty clear.

And of course, the reason for this is obvious. Our tigris.org front page has the following text: “The latest stable release of AnkhSVN was 0.5.5, released on August 17, 2004.”

Ouch.

So it’s been nearly two years since our last “stable” release. Why no releases since then? It’s not like there hasn’t been active development on it since. We’ve added tons of new features, gained VS 2005 compatibility and fixed lots and lots of bugs. “Snapshot” releases have been made at various intervals (the last one was yesterday), exposing users to the new features.

As I see it, there are primarily two reasons we never made an “official” release. First, most of the users we interact directly with are those who use the snapshots. Whenever we talk to someone still using 0.5.5, the first thing we tell them is to try the latest snapshot instead. There’s been something of a feeling that having the snapshots available is “good enough”.

The second is that work on Ankh, while it has never been dormant, has always been something of a fire-and-movement exercise. Every now and then, life and work interferes with Ankh development, and by the time I get back to it, there’s always a feeling of “well, we should at least fix this bug before a release” or “this feature needs to go in before we can call it 0.6”. Halfway into fixing those bugs and implementing those features, life and/or work interferes again, and the cycle starts from the beginning.

I’m starting to think this cycle needs to end.

There is no doubt in my mind that the current snapshots are miles ahead of 0.5.5 both in features and stability. If we took yesterday’s snapshot, renamed the MSI and released it as 0.6, it would be a huge improvement over 0.5.5. And it would definitely shatter the impression that the project is abandoned.

Maybe we should do just that. What do other people think?

Why Ankh isn’t an SCC provider

Thu, 03 Aug 2006 15:12:27 GMT

A question that comes up occasionally is why AnkhSVN wasn’t implemented using the Microsoft Source Code Control Interface (MSSCCI). This is a de-facto standard today for integrating source control into various IDEs and other application, so it would seem like a natural choice for integrating Subversion into the Visual Studio IDE. However, we chose to take another approach and implement AnkhSVN as a regular Visual Studio addin instead.

Initial planning on AnkhSVN started in December of 2002. At that time, it was a school project that was supposed to last throughout the spring semester of 2003 at Oslo University College. I had some clear ideas about what I wanted to do for my project: I wanted to make something open source, I wanted to relate it somehow to Subversion and I wanted to implement it using C#/.NET, since those were my interests at the time (and still are). Using MSSCCI conflicted with goals #1 and #3. In 2002, the MSSCCI API was under a strict Non-Disclosure Agreement, meaning we wouldn’t have been able to make something open source if we were to use it. There was also a rumor going around that getting hold of the right person inside Microsoft in order to obtain the documentation for the API and sign the NDA was something of a Kafkaesque quest. Since we didn’t attempt to go down this route, I never did find out whether this was true.

Another problem with MSSCCI is that it is essentially a specification for a number of exported C functions from a DLL. At that time I had dabbled with C#/.NET for a while and wanted to try it out for a major project. A .NET assembly cannot (easily, there are ways…) export regular functions, so implementing an MSSCCI provider using .NET would prove to be rather awkward. The technical problems here aren’t insurmountable, however, I can easily think of some ways in which we could have made Ankh using MSSCCI and still got to write most parts of it in .NET. If there hadn’t been other reasons for not using MSSCCI, this problem alone wouldn’t have caused us to make the choice we did. If MSSCCI had been the best choice, it’s also quite possible that we would have implemented the whole thing in C++ instead.

MSSCCI, unfortunately, has one more major problem: it’s not a very good API. It is more or less designed around the needs of Visual Sourcesafe, and source control systems that don’t subscribe to the same ideology as VSS plain don’t fit very well into it. Eric Sink (founder of Sourcegear, which makes the Vault source control system) , in his excellent series Source Control HOWTO, writes about MSSCCI’s deficiencies in Chapter 9: Source Control Integration with IDEs. Which is good, because then I don’t have to go on about it here.

We already knew about most of the criticisms leveraged at MSSCCI back when we were planning the project, so it proved to be the final and decisive argument against using it for Ankh.

Ankh: Why doesn’t “Add Solution To Repository” add all my projects?

Thu, 13 Jul 2006 22:14:37 GMT

The ”Add Solution To Subversion Repository” command in Ankh seems to be one of the greatest sources of confusion among Ankh users. They will often try to import one of their solutions and find that one or more of the projects are not included in the project. There is a message in the output pane stating that the project(s) could not be imported as they are not under the solution root. In snapshot 33, this was changed to display a warning dialog when projects in the solution were detected not to be under the solution root and allow the user to cancel out of the operation. This was added as the realization grew on me that this was causing a lot of users trouble.

So what is this “solution root”? Quite simply, it is the directory in which the solution file (.sln) is located. When performing the “Add Solution To…” command, Ankh will assume this is to be the root of the new working copy that is created. In other words, it will import projects that are located in directories beneath this directory (or in it), and omit those that are outside this directory.

Obviously, we could try to make a guess at some kind of common root that included all projects and use that. However, what if the projects are on different drives? Or if the only common root is the root of the drive? You really don’t want to import that. This is not an uncommon situation, with VS having a tendency to put web projects in C:\inetpub\wwwroot. Unfortunately, this cannot be easily dealt with, and there is also another complication with regards to this kind of solution layout.

Subversion does not allow you to commit items from two disjunct working copies in the same commit, even if the two working copies in question are from the same repository. So if you have parts of your project in a working copy under C:\inetpub\wwwroot and the remaining parts under D:\Projects, the commit will fail if it includes files from both locations. This is not something Ankh can work around in a reasonable manner. At best we could detect the situation and display a warning before it happens, but such an operation would be rather complex for not much gain. After all, if the commit errors out, no actual damage is done to the working copy.

I can think of two scenarios where this limitation in “Add Solution To…” is a problem:

The solution has projects scattered all over (as in the above wwwroot example).
All of the projects are in a single tree, but the solution file is not in the root directory.

For the first scenario, the only thing you can currently do is import the projects using another Subversion client such as TortoiseSVN or the command line client, then set up the working copies as you want them. The limitation with regards to committing items from disjunct working copies will still apply, though. For this reason alone I recommend against doing this. Restructuring the source to be in a single tree is far preferable.

For the second scenario, again, using another Subversion client to do the initial import is an acceptable workaround. Ankh will pick up on a working copy no matter what as long as the solution directory is under Subversion control. However, I think Ankh could do more in this scenario by allowing the user to manually specify the common root that is to be imported. Recent refactorings in the Ankh source would also make this easier to achieve; in fact, it would be pretty easy.