Home     Sign in    
By Simbey

I finally have something I'd like to share with the Internet!  So, listen up, Internet!  After using Subversion (SVN) for over a year at BSQUARE, I've decided I really like it!  In fact, I like it so much that I integrated it into my server!

SVN is a software versioning and revision control system, but you can read all the details at Wikipedia.  In a nut shell, SVN stores the history of documents as they are changed over time.  This is great for software projects where source files are constantly being changed.  Versioning and revision control make it easy to see how the software is evolving over time.

Out of the box, there are two ways to run SVN on Windows.  It can be run over HTTP through the Apache web server, or it can be run through SVN's native networking protocol on port 3690 from a module called SVNServe.exe.  It was easy for me to pick the native protocol, but I didn't want to run an isolated executable.

So here's where it gets interesting.  Since SVN is open source, I'm not stuck choosing between Apache or SVNServe.  It took some time, but eventually I had the SVN sources built.  I found all the prebuilt header files I needed on various websites, so I never had to run the actual SVN build system, which uses Python or something awful like that.

Finally, by July 21st, I had SVNServe.exe built and running, and I began checking-in changes to my new repository!  The solution wasn't ready for deployment, however.  SVNServe.exe needed to be a DLL.  Why, you ask?  Simple.  SVN usually reads user names and passwords from a text file, and this just wasn't going to work for me.  My server already manages user names and passwords, so why not share them?

By July 24th, both the SVN sources and the SimbeyServer sources were hosted in SVN!  SVNServe.exe had been converted to HostedSVN.dll, hosted within the SimbeyServer's process.  When a client authenticates, SVN asks the SimbeyServer, through an in-proc interface, to verify users.  The SimbeyServer hosts its own source code!

Next problem...  SVN uses a cross-platform compatible library called Apache Portable Runtime (APR).  APR's actually not that bad, especially when compared to Nokia's Qt, which is a train wreck.  No one should use Qt.  EVER.  Know what uses Qt?  Amazon's desktop Kindle app.

SVNServe.exe, now HostedSVN.dll, has a loop that listens for incoming connections and creates a thread for each connection.  The method for exiting the loop involved closing the listener socket from another thread while the main loop was blocked within APR's apr_socket_accept() call.  Not exactly elegant.

The SimbeyServer already has a thread that manages all the listener sockets using the WSAEventSelect() model.  By August 2nd, I had eliminated the extra thread within HostedSVN.dll that was listening for connections, and the listener was being managed by the SimbeyServer's listener thread.  When a client connects to port 3690, the SimbeyServer passes the socket to HostedSVN.dll, and APR's apr_os_sock_make() API is used to wrap the socket for APR compatibility.  And the rest of the system continues to work as before!

And that's my story!  SVN is fully functional and, thanks to TortoiseSVN, is user-friendly!  So where do I go from here?  As crazy as it sounds, I may go grab K-9's sources and add them to my repository.  Once I have a little extra money, I might hire out some work.  With SVN, collaborative software development becomes very easy!  And there is so much I want to do!

© 2001-2019 Simbey.com