Tag Archives: Subversion

Next Steps For HareSVN

Posted by on October 20, 2009 No comments

I thought I’d let everyone know what my future plans are for HareSVN (and hopefully not too far into the future). But first, I want to let everyone know a few key things that have already taken place.

I’ve been working on various prototypes to verify a couple of things. For example, I have a prototype that I created to make sure that wxWidgets meets my requirements. I need the ability to render overlay icons efficiently. For this task, I chose to use their fairly new wxDataViewCtrl widget, which is supposed to be a “better” version of wxListCtrl, which the wxWidgets developers have openly admitted they hate (the wxListCtrl that is).

I can agree that wxDataViewCtrl is better. It uses a model/view design which helps separate responsibilities, which is something wxListCtrl failed at doing. Additionally, it also lets me specify a renderer for each of the items in the list, which allows me to have very granular control over how I draw the icons in the list (I can blend two icons together to provide overlay support efficiently on a per-item basis). There is one sacrifice I make by using this widget, however, and that is functionality. Unlike wxListCtrl, wxDataViewCtrl does not support various view modes, such as icon or thumbnail views. For most programmers using Subversion, this wouldn’t be such a big deal since we normally use report/list view anyway. However, for artists using Subversion, I suspect that a thumbnail or icon view would be useful for them. This is a situation where my hands are tied. Unfortunately I am stuck with what wxWidgets provides me. I’m hoping this improves in the future, though. For now, I’ll be sticking with wxDataViewCtrl.

The next thing I have to do is learn the Subversion C API. I already have a second prototype in progress that is really just a simple use case for Subversion. I want to make sure I fully understand the API and how it works before I begin writing a set of abstractions for it in C++. Once I feel comfortable with Subversion, I’ll begin working on HareSVN (no more prototypes) and start with a very basic interface and functionality (e.g. connect to an SVN repository, get the list of files, display this list to the user).

A friend of mine has offered to help out with HareSVN development once it gets going again, and I am very grateful for his offer. As I said before, right now I’m helping out Red Sword Studios, which is consuming my free time that I would otherwise be putting towards this project. However, when I’m done there I’ll definitely be back on HareSVN!

Dependency Management in Version Control

Posted by on October 6, 2009 No comments

Hello everyone,

A few months ago I came up with a pretty great way to manage third party dependencies in projects and I’d like to share it with the world. In my experience, dependency management has been pretty straight forward. If I am working on a project that uses three different open source libraries, normally I would compile them into binaries and commit the headers and the libraries into version control. There are a couple of drawbacks to this approach:

  1. It consumes an enormous amount of storage space on the server. On a standard HDD, this opens the door for more fragmentation and could actually affect the performance of your version control system.
  2. It consumes an outrageous amount of bandwidth. Whether you all have your own tube or you share one, this is bad and checking in new libraries or updates to existing ones could mean a 30 minute update that blocks your entire team.
  3. Depending on the version control system you use, it could slow down the performance of your working copy. For example, updates could become slower because there are more directories to recurse and larger files to process. With Subversion, the extra recursion depth can really kill your update speed locally, not just in bandwidth.
  4. If you are targeting multiple compilers or platforms, you will have to build and maintain multiple copies of the binaries for each third party library you have. This is a maintenance nightmare for a team.

Some teams have solved a few of these issues by creating a compressed archive of all of the pre-built third party libraries the project depends on and placing that on a server somewhere separate from the version control system. This creates a few issues of its own, however, such as complicating the checkout process. Ideally checkouts should be as close to one step as possible. It also doesn’t solve some of the more annoying issues, such as point #4 in the list above.

I believe I’ve come up with a solution that addresses all of the issues above. In my opinion, this is the best solution to maintaining third party dependencies for a project. In a simple case, simply write a script that will download, build, and install (i.e. restructure libraries’ headers and binaries locally to the project in a way that it expects them to be hierarchically) each individual third party library your project depends on. For example, if you wrote this script in Python, you would be able to make it portable so that it would build those libraries appropriately for every platform you are going to support.

I have implemented such a script in my HareSVN project and it works pretty good. For now, however, it only works on Windows as I do not have the resources available to test on other platforms. But if anyone is curious to see it in action feel free to do a checkout and test it for yourself!

About HareSVN

Posted by on October 2, 2009 No comments

On my spare time, I usually work on my personal open source project called HareSVN. It’s a fairly ambitious project with the goal of becoming a portable, GUI Subversion client. For those who have heard of TortoiseSVN, it will follow the same design principle for the most part. You will be working out of a context menu to access most of the features and functionality. The big difference is that HareSVN will not be using shell integration. This can’t be done in a portable way since features vary between platforms.

Because shell integration will not be used, this means the program will come with its own file-browser. I aim to make it follow the same look-and-feel of Windows Explorer on Windows XP. However, the interface design for this has not been started. I’d post some mock ups if I could. However, the basic vision I have for it is that it will be very familiar to what you use already (Windows + TortoiseSVN).

I’ve always loved TortoiseSVN, and I think Stefan and his team has done (and continues to do) a great job on this piece of software. However, there are some architectural issues, such as portability, that cannot simply be added to TortoiseSVN and would require a full rewrite anyway. I’ve taken it upon myself to start a new project that will hopefully address some of the missing features I always wanted in TortoiseSVN.

Oh, and why did I name it HareSVN? Because when I hear “TortoiseSVN”, I think of the fairy tale “Tortoise and the Hare”. Yes, yes… I know the hare loses :(