The year is 2009 AD. Development is entirely occupied by the Text File Environment. Well, not entirely … One small village of indomitable Coders still holders out against the invaders.
(Paraphrased from that most excellent of stories, the Asterix series)
I work with Binary files. That’s right. And I’m okay with that.
However, as with that small village of indomitable Gauls, it’s a big world of text-editing coders out there.
If you fire up SVN or CVS or VSS (three letters seems to be the norm), they are built around having many developers working on text files and who want to merge and branch and slice and dice. Fancy stuff.
Source Control with Binary Files just doesn’t work the same, inherently.
“Yeah yeah” You say. “Stop boring me and being lame. We all know that.”
Actually, I had head knowledge of this truth for a long time, but until the last week when it was tested, I truly did not _know_.
We have a small development team, but it’s larger than one. There are three of us who work with a development tool that creates binary files. Sure, there are source files that are text, but we don’t work IN them, usually.
Circumstances changed over the past couple of months, so that we had to implement a serious (not just copy and paste backups, which I do with great gusto, having retentive folder structures and the whole kit) source control solution.
Having used Tortoise SVN for a couple of years for myself, I put my hand up to implement that.
It worked, until the “multi” part of multi-developer kicked in.
It failed big time.
Why?
Because of two reasons:
– I didn’t know Tortoise SVN well enough. All my limited experience had been single-user. We needed a solution that would work multi.
– I did not ask the right questions. Yes, SVN can handle what we need (explanation of that coming). But I didn’t ask the right questions when doing some research into it to find out HOW to get SVN to work.
The big problem was that, out of the box, Tortoise SVN doesn’t stop you from committing files other people are working in.
Yes, it allows you to lock a file. And yes, you can make it work this way. But this requires more knowledge and understanding than I had at the time.
So we turned to Visual Source Safe (the VSS from above).
Out of the box, after a nice MS wizard, we populated the repo and assigned our working folders. It makes all the files in the repo read-only. Which means our “app” files are read-only. Which means we’d actually have to make the decision to “UN” read-only them before we could get around the problem. And that step is one big wall in the way of accidental code loss.
What’s my point?
If you develop with binary files, in a multi-developer environment, make sure your Source Control implementation stops you working on a file unless you’ve checked it out.