I'd rather have a SVN backup, so we can keep the revisioning.
I don't think it would be wise to have only a git mirror when the actual workflow is in SVN. That doesn't mean however, that we mustn't have a git mirrror. From my experimenting with git-svn, this can range in difficulty from trivial to extremely hard. In the former case, nothing speaks against it. (the predicament is, that the one thin where a git mirrror is specifically requested is the difficult case
Pracitcal part of the reply:
Conversion from SVN to Git with git-svn keeps the SVN history, each SVN revision becomes a git commit. There are now two questions associated with this (a) is all information retained? (b) do you need some specific datum of information that is lost, not easy enough to find, incomplete?
With (b) I'm asking for things that SVN users only really know, based on their workflow, perhaps you really need the revision number? Or the fact that each repository has a sequential numbers with gaps, since the revision counter is incremented for each submission to SVN, might cause problems. The question is so vague as I can't really anticipate what is really needed.
Could you perhaps have a look at the git repository of pak128https://github.com/simutrans/pak128
in comparison to the SVN and tell me if and what is wrong, if something is needed or desired?Edit:
better have a look at the source mirror:https://github.com/aburch/simutrans
One mirror of the files can be GitHub, we already have an official account and we could upload there. GitHub allows uploading any file type on their release feature.
Having more than one mirror doesn't hurt, with one caveat. All mirrors have to be kept up-to date. Now, that is perhaps something we ought not load on Prissi's shoulders who publishes the releases. However, simply copying the file from SF and loading it to other mirrors would defeat the point.
However, simutrans git does at the moment not have the actual simutrans source code mirror. That is done by Ansgar (aburch). It is not only impolite, but also against github's rules to use it as a fileserver only. We can distribute the binaries, of the sourcecode we have there. The simples way could be to just clone and pull from aburch regularily. Can we run into trouble in case he stops his service? Perhaps I can ask him if he could add a repo under the simutrans account as a second git remote location, that is next to no effort.
This also fits to something that is not directly related to SF, but to the release process. It was very dissapointing how the last release was overlooked. I simply lost the habit to check the relase thread regularly and haven't any rss reminder system set up. But I've not been the only one who overlooked it.
Can we think of a way that does (a) not increase Prissis workload, (b) makes sure all who disseminate information are informed, (c) provides those who maintain official mirrors (to come) with the original file, as compiled by Prissi?