Hi Chris,
yes, SubGit meets almost all the requirements with a slight nuance, here are the details:
Commits to one system are mirrored to the other, with little or no difference in the result regardless of which repository platform they choose to commit to
yes, this is how mirror works, it is supposed to translate commits from Git to SVN and back with no difference. SubGit is able to make changes during the translation, however: for example, it is able to exclude some files from the translation or change EOL style on the fly. But it all depends on configuration, by default it translates data without changing.
User ID behavior is unchanged, commits on both systems occur with the user’s own identity
yes, SubGit is also capable of that, but it needs information on mapping between Git and SVN users. This mapping is called “authors mapping” and should be provided to SubGit as an “authors file” or a program that’s able to return author name on the request, here are the details on authors mapping:
https://subgit.com/documentation/authors-mapping.html
When SubGit translates an SVN revision, for example, it takes the revision author name, finds mapped Git user entity and sets this found entity as an author (or committer, depending on settings) of the translated commit and vice versa for Git commits. Thus translated commits and revisions have correct authors.
Users authenticate with their SSH keys, as they do now.
There are several authentication methods SubGit supports:
https://subgit.com/documentation/auth-book.html
Among others, it supports using certain credentials for every single user. However, it only works for passwords, but not SSH keys. SubGit does SSH key authentication, but it can only use one key.
However, using single SVN user entity for SVN login is actually a common approach. There is no need to set every user to use their own credentials for mirror – instead, you can set a single SVN user (usually, a special service user account) for the mirror specifically and that would be enough for mirror to work well. Authors mapping will work with this approach, too, SubGit will be setting correct authors for commits and revisions, too.
As an administrator I must NOT handle or know users’ passwords or private keys. I can only handle their public keys if needed. I can NOT ask them to place a public key in their authorized_keys files, which corresponds to a private key that I hold or have handled.
This is not needed with the ‘service account’ approach I described above, you would only need to handle single key for that account and that’s all.