Recently I have been working on CodePlex's SvnBridge. This is an ambitious project, attempting to give a Subversion client the impression that it is working on Subversion while the real back end is a Team Foundation Server.

I would have said that this is not possible, if I was asked. But not only this is possible, the CodePlex team actually got that working.  A tiny disclaimer here, it is not 100% complete, but it is close enough to that that you can work normally with that without much issues. Some things still do not work, but they are generally uncommon features, and I am working on that.

I have been working with the code base for about a week, and I have a few observations to make.

Tests, tests, tests. The SvnBridge has close to one thousand tests. And each and every last one of them is appreciated. I have to do things in the very guts of the system, and having tests to cover my back is the only thing that actually enabled me to do so.

Forget about the backend, what makes a source control is the protocol and the clients. SvnBridge has actually very little to do with TFS. If you implement ISourceControlProvider, you can use an XML file as the backend. No one will know. That might be a really cool way to plug into a temporal database, by the way.

The reason that I mention this is that lately I have been working on figuring out what to send to the client on an update request. The SVN protocol is very interesting to examine, because it carries a lot of the behaviors that SVN has.

As a simple example, and update request can be "from #123 to latest", "from #123 to #125", "from #123 to #121" and, last but not least, "from #123 to latest and blah.txt from #121 to latest".

This means that from the perspective of the server (SvnBridge), in this case, we need to do some pretty interesting stuff. I am not sure how Subversion handles this, but TFS, at least, has a different model. So when SvnBridge accepts such a request, it needs to figure out what to do with it. That is, given the request from the client, it needs to calculate the diff that will be sent to the client from the version that is currently on the server.

That part is handled here, this is a pretty important piece of code, to say the least. It is also pretty hairy at the moment. There are a lot of edge cases to cover (all of them, I have to mention again, were covered by tests, making it possible to change that safely, pure bliss, compared to the alternative).

Anyway, I just wanted to give you some heads up about that. It has gotten some new features, and I plugged a few bugs. Right now my priority is to fix protocol level bugs, and then some of the higher voted issues, and then put a lot of focus on performance.

Feel free to drop in the discussion board, I read that when the integration tests are running, and it doesn't get enough visitors to make it really interesting :-)