That's the best part: if you have access to the source SVN repo you can change history and there will be no evidence that you did so. History in Git, on the other hand, cannot be modified without it showing up.
The reason is that in Git every commit gets its own unique hash so you can't change a commit without creating a new hash. To have this in SVN you have to buy 3rd party tools.
I do not think it is as black and white as you describe it. The way I see it: if somebody falsifies a complete repository, the only way to detect that it was changed is by comparing its content or a hash thereof with that of a (supposed) copy that is more trusted.
That is true for any digital archive, including those made by any SCM system. The only thing where git differs from svn in that respect are a) that it computes such hashes for you, and (typically/AFAIK) shows those hashes in its UI, and b) that it is typical for people to store those hashes on other systems. The net effect of that may be large or small, depending on the number of people keeping a copy who will not blindly copy changes from the 'main' repository.
>I do not think it is as black and white as you describe it. The way I see it: if somebody falsifies a complete repository
No, it is. You can't "falsify a complete repository". We will all have checked out from that repo and as soon as someone replaces it with a fake none of the hashes will match up.
>the only way to detect that it was changed is by comparing its content or a hash thereof with that of a (supposed) copy that is more trusted.
Which happens in the system automatically. Have you actually worked with Git? Go change history on something you've pushed and other people have pulled.
>number of people keeping a copy who will not blindly copy changes from the 'main' repository.
It's not about "blindly copy changes". If you pull from a repo where someone has tried to rewrite history you'll see duplicate entries all over your log. If you have a graphical tool you'll see right where they started their modification.
As I understand it, if the repo has receive.denynonfastforwards=true, a user can't push changes that will destroy history. This flag has been available since 2006. (And I didn't mod you down. You ask a legitimate question). A bit more research shows that there a couple more config changes required: http://stackoverflow.com/questions/2085871/strategy-for-prev...
I don't think it's easy to do. You can change a commit message, but even that's not easy (you basically need admin access to the repo files).
If you want to edit the contents of the repo I think you need to read > filter > rewrite the whole thing. I could be wrong about this, it's been a while since I thought about it.
Which is utterly trivial (I've done it, seriously, it's not the big deal you seem to think it is, aside from the obvious difficulty of particularly large repos), and is not conceptually different from what's necessary for editing git's history, except that nobody can tell you've done it without comparing the "new" repo to the old one -- and under svn's internal model, no one but the server will normally have a complete history.
With git's model, not only does everybody have the history, but the commit ID themselves are your insurance against tampering. You effectively validate that history every time you sync with another git repo.
