Good version control needs to be …

… topical.

CVS was a nightmare because it let you nest branches ad-nauseum: it simply created a new dot with a new numeral below where you were, e.g. if you branched it became

SVN lets you create your own branch hierachy, just don’t count on anything to really understand it.

For many projects branches are significant ancestry points of the project. The version that supports Windows 8, 64-bit work, etc.

But this branching concept doesn’t help with agility, test management, feature management or anything but small projects.

A “topic” has a relatively short life time and is supposed to comprise a subset of changes, e.g. a particular feature, being prepared for addition to a branch. You might consider two types of topic, branched (that is, they are based on a specific revision of the branch they descend from) and floating (that is, they are represent a change set to the head of the branch they are descended from, whenever you refresh the working copy, the changes are shelved, the head is updated, and then the changes are re-applied).

The sole purpose of topics is for them to be merged upwards, e.g. when they’ve been tested and sanctioned.

There must be a VCS (aside from Torture-force, I mean perforce) that does this?

Git: It *could* be harder.

Some time in the last two weeks, I pulled some code from somewhere, made some changes, and dispatched them to the author for review.

Then I scratched my head. I’d just used git.


Thinking to 1.32

1.31 (or the lack thereof, as yet) has been almost as frustrating for us as it has for our players. It is likely to become known as the “if I’d known that” patch.

I’ve been wholly mired in cell host performance issues for a while, stuck in the maw of code that I really, really, really hate. Code that resists or springs a leak at every turn. It is the code that any sober refactorer would say rewrite to.

But it’s not just some subsystem, or some corner of code. It’s the fundamental basis for the cell host.