Originally Posted by modrobert
Perhaps obvious, if it ever comes to that, is to store the whole source code (tags and all) in a "read only" public SVN repository for preservation and historic purposes, and push the latest "working" 3.1 version mix to GitHub and let it fork off from there, starting fresh.
This is likely to take a lot of work to compensate for the loss of (for lack of a better word) "metadata" which the individual module history tags represent. I expect that this would likely to impact productivity more than the productivity gains attainable from switching to Git could compensate for.
With the tags gone, it becomes difficult to track which release each collection of files corresponds to. And let's not get into the bigger problem of matching those tags against the respective operating system release which they are a part of. There are V36 components in Kickstart 2.04 (V37), 3.0 (V39) and 3.1 (V40), there are V39 components in 3.1, etc. The version numbers of components were usually changed only if the respective code would no longer work with earlier releases, which explains why it looks like patchwork.
The tags are like "thumb tacks" (there's a pun there somewhere, I suppose) which pin down the collection of files that makes up a specific version. It's fundamentally what "software configuration management" tools are supposed to be doing, so it's not an "expendable" property of the subversion repository.