Hmm …

Really? I mean, anything can be encoded into an integer, technically—Git commit IDs are just integers after all even if they are represented as hex strings—but I wouldn't say the base version of an arbitrary Subversion repository "fits nicely inside an integer" given its support for mixed-revision working copies and independently-versioned external references:

> $ svnversion
> 3500:4122M

That doesn't even tell you *which* parts of the working copy are from each revision, just the lowest and highest revision IDs.

Even without mixed revisions, externals, or local modifications, a single revision ID is not enough to recreate the state of the working copy: you also need to identify the repository URL and the path of the branch. Contrast that with a Git commit ID, which uniquely identifies both the content of the checkout and its history.

> It probably is used, but I don't recall it being used in snapshot release names.

I have at least 45 packages installed on my Debian system right now which use the Git commit ID as part of the package version. IIRC if you build a kernel from the Debian source package it uses the Git commit ID by default as part of the kernel version.