[...]
isn't this scenario a somewhat basic feature of a version control system ? doesn't every SCM support that ?
Yes it is, but there were some misunderstandings that needed clarification.
the designers of svn would have done well to declare the repo history as immutable - what goes in stays in. if you need to change it, commit a new revision. don't alter history, don't modify the past. [...]
i had a developer run a script that was supposed to 'fix a few things' in the repo history. seemed to work ok on his test repo, but truncated commit messages in the production repo and shifted them by a few commits. this effectively rendered the repo useless.
Now I guess you've heard of backups, that's what they re supposed to protect from. Note that hooks are an entirely optional feature managed by the admin, not the developers.
the canonical way how this is handled in git is to submit a new revision that fixes the mistakes in the past. you can modify the history in git, but this will hickup once you push them upstream, so you will do this only once: http://book.git-scm.com/4_undoing_in_git_-_reset,_checkout_and_revert.html
This is a fair point in favor of git, but I am not sure this is a compelling reason to switch by itself. Julien