AlliedModders Planning

The complexity of SourceMod's branching (even as trivial as it is) is too much for Subversion and our build process. I'd like to discuss a move to Mercurial. Almost everything in this document can be done without Mercurial, but such a move would require the changes anyway.

Overview

Subversion doesn't let us branch nicely or create user-specific branches without forever mucking up the central repository. It's difficult to do merges. Mercurial seems to solve these problems, but our build process will be majorly affected.

The Revision Problem

Mercurial tracks revisions with 160-bit IDs (40 digits of hex), called "changeset IDs." Mercurial has aesthetic revision numbers only; they're not guarantees like they are in Subversion. Revision numbers are properties of a repository clone, not the overall repository. This means that if two people make changes locally, those revisions will be different, and will change again once pushed upstream.

This problem is somewhat mitigated by the fact that the central repository will have reliable revision numbers, but that's still not good enough since branching will generate multiple revisions. Branching also makes the revision numbers awkward since users assign meaning to them where none exists (for example, "1.0.1.1234 versus 1.1.0.1231 doesn't make sense because 1.1 is later than 1.0.1").

This means we must change SourceMod to not use revision numbers, a change we should make regardless of a Mercurial merge. The major problems to keep in mind are: What do we display for the version number? and How do we keep fetchdlls working? (Fetchdlls needs to be able to get a changeset ID from the MINIDUMP_MODULE struct, which has a checksum and version info.)

Solutions

There are a few ways to go about this. These are the two I came up with while writing this.

• Revision numbers that are per major release. We'd have a "build number server" that would dish out new numbers on request. These numbers would be used by the build scripts.
  • A decent bit of work but would preserve the most compatibility with fetchdlls.
  • [svnrev] (or [hgrev] or whatever) would have mismatching revision/build # ids which could get confusing. Thus we'd have to try and not display the revision numbers publicly (they'd only be used for linking).
• Simply assign 0 to the build number and ignore it entirely.
  • Seems easy but we'd need to have a mapping between VS's "checksum" values and a changeset ID if we wanted fetchdlls to work. Not too difficult really as this could be done with a simple HTTP push.
  • For visual display, we'd totally eliminate the build number. It'd only be visible on Windows from the file information.
  • We'd add a secret date+time field to plugins that would be filled in by the compiler.

For plugins, displaying a timestamp is not a problem. We could put some sort of "public String:__date[] = __DATE__" into core.inc.

Automation

Right now we use subversion for all of the packages. This is getting to be troublesome. It makes fetchdlls extraordinarily complicated when it really does not have to be, and the hourly builds just accumulate with no way of being deleted. The package repository is 1.7GB and growing.

It would be a lot simpler if we could just throw a single package on the webserver and forget about it. We could even keep a rotation of, say, 30 days' worth of packages in a rotation. This would let us remove cruft and keep enough binaries around for debugging. The problem is that people rely on the repositories to perform diffs.

I don't have any good ideas on solving that problem, because there's no way to selectively rotate things out of a versioning system. The only solution I can think of is providing people with, say, a perl or bash script that does the job for them. This could go through two routes: using local repositories, or simply doing a HTTP fetch from the web server and then doing a diff.

License Changes

I don't want to keep hacking up our private->public sync script. DS has faithfully maintained it until now, but I believe he will be as glad as I to do away with it. A move to Mercurial would have either of the following benefits:

• We could keep the JIT closed source and shove it in a private repository, OR
• Just open source the thing finally, it's not very special, and have everything be together.