Someone has checked in 20 files as part of a logical chunk of work they are doing.
Unfortunately they did this as 20 separate commits. This makes me a sad-panda
Is there anyway to purge these commits from the repo and then re-commit them in a single go?
Alternatively is there a way to bundles these changesets together to prevent someone checking out the code at one of the revisions in the middle?
Lets say the revisions are 1001-1020. What I want to prevent is someone being able to merge/branch/tag on one of the unstable broken revisions (i.e. 1001-1019).
Even being able to mark/flag those 19 mid-state revisions as non-mergeable/non-branchable would be helpful
Although I agree that this was a bad idea of the developer, bad revisions in a SVN repo (revisions that make the build fail, that make the unit tests fail, etc.) are common, and expected. That's why we use continuous integration.
I don't see any reason why any developer would randomly choose one of the bad revisions to start a branch. They will certainly branch from the head of the trunk (for a feature branch), or from a tagged revision (for a maintenance branch).
If you want to make sure only good revisions go to the repo, you should probably have two repos: one for actual development, and another one which aggregates several revisions from the dev repo, and to which changes are committed only when they are verified. But I don't see any good reason to do that.
