This week I was without internet but with netbook; which left me somewhat free to code whatever took my fancy. So, armed with the latest mercurial release and as much info on the API available (read: very little) I set off to build something fun.
One project I've always wanted to try and complete is a standalone IDE for EventScripts. ES users tend to consist of fairly new entrants to the programming language so modifying an existing IDE is probably too hardcore an approach. It needs something a bit more gentle with lots of ES related buttons and hints littered around. So this was the project I mostly hung around on.
Mercurial fits into this quite nicely; originally I wanted a way to backup projects to a mercurial repository (this would be handy for me as I use BitBucket extensively) and so drafted a kind of wrapper to mercurial to make commiting, pushing and pulling changes nice an easy. The Mercurial API is far from what I would describe as "good" but once you get to grips with it things eventually make sense. It didn't take long to have a working prototype.
The next step I wanted to look at was creating a save package. The IDE is mostly designed for creating EventScripts Addons - folder packages containing some ES code to load on a game server. The current IDE stores these packages in folders in a single location identified by their "basename" or folder name. The issue is that it isn't hugely portable; having to copy folders between computers while maintaining the right structure is obviously prone to cock ups.
The solution initially was to zip up the folder and create an export package which can be transferred and unzipped at the other end.
Then it struck me: Mercurial is incredibly portable. I can pick just the .hg folder off the disk and shift it to another machine (even a different OS) and quickly load up the latest working directory with a few commands. It is, in fact, a really nice, versioned package.
So the new method is quite simple and highly effective: zip the .hg directory and drop in a single meta-data file that the IDE uses to load the addon correctly. To "open" such a package the IDE only has to check the meta-data for relevant information, create a directory, drop in the Mercurial repository and "hg update". Not only do you get to transport the entire package but you also get the entire version history.
I think this is a really neat application of version control. I know a lot of programs already implement their own forms of rudimentary version control (Word for example) or backups (NP++). But surely it makes more sense to use a mature versioning system rather than custom build your own. By using Mercurial my IDE now is pretty compatible with anything else that might be useful. For example you can simply push to a remote Mercurial repository and you have it accessible online.
The user still gets a single package in a form they understande (i.e. one file == my entire project) but there is much wider scope to do things with it!
Some bullet points:
- There is the downside that you are carting around an entire version history - which could get big. However the biggest ES project I know of is less than 8MB which isn't the end of the world. Most are a few KB at most
- Mercurial is GPL. Which is a bit of a pain because I much prefer MIT/BSD licenses for my work. Any released IDE would have to be GPL... which sticks in my craw.
- EventScripts has it's own package repository ESAM. This allows you to add collaborators on an addon. Mercurial is great because you can have collaboration and linking the 2 ideas wouldn't be hard. If the package was hosted somewhere online (say BitBucket or even a custom ES solution) valid collaborators could work on the project together merging their changes.
- Merging is a sticking point. Most of the time it works fine, sometimes it needs user input. Avoiding this is a catch 22 and ignoring it is just going to lead to massive gotcha's down the road.