git filter-branch. That of course modifies the repository and changes the hashes that are up to now linked to the SVN-revisions. Therefore in a second step these linked hashes need to be replaced in the revmap file of git-svn located in
.git/svn/refs/remotes/origin/trunk/.rev_map.[UUID of the SVN-remote from .git/svn/metadata].
greping for old hashes and replacing them in the found files then did the trick. So now we can do a test run on a box that we can set up a cronjob on that can then push the modified repo to the php git server.
git ambut that would then again raise issues with the modified content.....
With the svn translations, the translated file contains 2 revision numbers. The en revision on which this lang revision is based. The en revision is updated by the translator when they make their changes ... "We are upto this point on this file" sort of thing. All worked great.
In git, due to hashes rather than sequential numbering, not so easy.
So. What if. Rather than maintaining the association in file, place that information elsewhere. Tooling would be required. Amending an entry in svn would add a new entry in the index. Editing a file in git would look at the index to see what the revision number was for the source file. Sort of keep both svn and git in sync via an index?
I've got zero idea on the complexity, but it would allow svn to be svn, and git to be git, and we have glue to hold them together.