Subversion in my Delphi IDE

Subversion in my Delphi IDE

For over a year, I've been using Subversion version control software to manage my source code, with TortoiseSVN as client on Windows. I find TortoiseSVN extremely helpful in my everyday work. It's implemented as a Windows shell extension (so it's integrated with Windows Explorer) which makes it very comfortable to use.

For the last couple of days, I've been trying to write my own Subversion client and integrate it with my Delphi IDE. The picture above shows my humble first results.

There's Subversion client API but I had to use Microsoft Visual Studio to create a DLL to expose it to Delphi because Windows builds of Subversion link all the relevant code statically.

Then I had to write import units (translation of C headers into Delphi) to be able to use the DLL in Delphi. Subversion uses Apache Portable Runtime library, so I had to translate those headers, too (fortunately, APR on Windows does include DLLs). BTW, I find my own Delphi keyboard macro manager quite useful for translating C into Delphi. :-)

Today I finally used Delphi's new FileHistoryAPI to write a Subversion history provider which is shown in the screenshot. This part seems to be very straightforward.

This pet project of mine is in a very early alpha stage now. My header translations are incomplete and some parts are probably incorrect. Also, I don't know Subversion and APR internals very well yet so it's quite possible that what I'm doing can be done in a much more efficient way.

I plan to work on this project in my free time, extend it bit by bit, and when I have something stable and usable enough I will upload it to Borland's (or the new "DevCo"'s ;-)) CodeCentral.

Delphi 2006 Demo

There's a nice new demo on Borland's website showing features of Delphi 2006:
Delphi® 2006 - The First Choice in Windows Development

CC2209 fix

I've just fixed a memory leak in my entry #2209, titled "Access client's IP address from a DataSnap remote data module" on Borland's CodeCentral.

The problem was on the COM server side, in the included DSnapCom unit. The client's IP address (passed in by httpsrvr.dll or scktsrvr.exe as an additional BSTR parameter) was not released properly, which caused a few bytes of memory leak for each method call.

Looking back, this bug seems pretty obvious, and it seems strange that I didn't discover it at the time when I wrote the code. I was under the impression that I had tested everything properly. Duh!

Oh well. It's back to testing then. (I've discovered this while trying to solve another problem which might or might not be related to it.)