Through 2014, I had every once in a while heard people casually mention that they were versioning their projects in a combination of git and SVN. I didn’t really take the time to ask for details on it, but it was one of those things, stuck in the back of my mind.
Filed under “delightfully mad hacks”, I finally found some time to look into it over Christmas – as I was dodging various boring tasks in finalising Behave 2.5.
The Excuse
Git is lovely for its decentralisation, easy branching and a bunch of other stuff. However where it is not so delightful is in its handling of binary files.
One alternative VCS which is pretty good at handling binary files is SVN. So by putting binary project files in SVN and text files in git, you should be able to get the best of both worlds, right?
That is the idea anyway.
The Hack
Regardless of whether it is a good idea or not, it is an interesting hack. Immediately, it seems like a terrible idea with way too high a potential of user error from its silly workflow overhead. So that is where we’ll attack.
The goal is then to have the user place binary files in one folder and text files in other folders – all under the same core project folder. And then simply commit, update and branch as normally, in the knowledge that everyones local drives will not explode with tons of versioned binary data.
Our primary concern is keeping SVN and git in sync – with the proper commits connected. No-one likes SVN, so we’ll hide that away and put git in the driver seat.
Luckily, git operations are also fairly easily customised on a per-repository basis, which is perfect for this case.
The idea will then be to have git operations keep track of the SVN working copy, making sure that everything there is committed before a dependent git revision is committed, at which point a versioned text file with the corresponding SVN version number, should be added to the commit.
This way, SVN becomes a dictionary of collected binary files, into which git adds new versions when committing and fetches copies when updating – using SVN version numbers as key.
Git Hooks
Our entry point in automating this stuff with git is in the so called “git hook”. These are scripts located at “.git/hooks/” for any git repository. Per default, this folder is populated with a few demo scripts, each containing an example of what to do in response to that particular git event.
For this hack, the two points of interest are:
- The commit process – cancelling the commit if the SVN working copy is not clean, otherwise getting its current version and adding it to a text file in that same commit.
- The checkout process – updating the SVN working copy to the version specified in the text file, every time a git checkout has completed.
This means that the files we are interested in are:
- (Git clone path)/.git/hooks/pre-commit
- (Git clone path)/.git/hooks/post-checkout
Note that these files are not by default versioned with the rest of your git repository, though I do recommend doing so anyway. For this hack, I chose to address this via a setup script which needs to be run once after first cloning the repository – as well as after performing any updates to the versioned hook scripts (which I’d estimate happening just about never).
Solution
My weapon of choice for this sort of hackery is Perl. If you would rather use something else, that is fine too – as long as your shell can run it, you should be fine.
Since we’re in glorious hack land, I chose to take it further over the top by expanding the text file with the SVN version to be a full JSON-formatted configuration file, with the option of overriding parts with per-user local configuration.
The project structure is as follows:
- .gitignore – containing ignores for the local user config as well as the SVN folder.
- VCS/ – this is where the core perl scripts are kept, as well as configuration.
- Setup.pl – the run-once script for copying the hooks in etc.
In the linked Git repository, the example configuration has also been set up for a Unity project – with the SVN working copy placed in Assets/SVN. Though aside from this, nothing here is specific to any technology aside from Git and SVN.
Additional over-the-top-ness:
- Place a JSON formatted file at VCS/LocalUserConfiguration.txt to override select values from what is set in the versioned configuration file.
- Setup.pl will check for a working copy at the specified SVN path and run a checkout from the specified repository if none is found. So this is really a one-stop-shop kinda thing.
- “autoCommit” and “autoAdd” options for mad driver-less running.
- “autoCommit” will, if enabled, see the commit script run SVN commit to push any local SVN changes as part of the git commit process.
- “autoAdd” is for off-your-rocker “Look, ma! No hands!” setups, where any unversioned files found in the SVN folder are automatically added to SVN as part of the git commit process.
Why no “ignore unversioned” flag? In the example configuration, the SVN folder is put inside a Unity Assets folder. This means that contained files are imported as part of the project and project files outside of SVN can depend on them.
If you have no problem risking gun-to-foot related injuries with commits missing dependencies, that’s just fine. However I will not assist you in the loading of said gun.
I hope that you find this stuff interesting as well – if not useful. You can find everything at the other end of the below github link and I would be very interested in any feedback and discussion (preferably over twitter).
Are you employing a similar combined VCS setup? Are you in fact one of those who mentioned using the git+SVN combination in particular? Do you have a suggested alternative to this madness?