2

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

Eoin Campbell
  • 43,500
  • 17
  • 101
  • 157
  • Can you not revert back to say, 1000. And then re-commit as one go? – Moo-Juice Dec 13 '11 at 10:11
  • 1
    Without a dump, edit & reload I doubt it, sorry, and I don't know a mechanism to mark them special for the client. The dump / reload is a bit drastic really and would also cause problems for anyone with a WC in that range. Your easiest option might just be email around your dev team and 1) warn them off those revisions 2) explain how you'd like them to commit. – Rup Dec 13 '11 at 10:13
  • @Moo but then the revisions would still be there in the branch history for people to see and check-out - there's no benefit to just leaving revision 1020. – Rup Dec 13 '11 at 10:15

2 Answers2

4

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.

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • I guess your right. Maybe it's just my Obsessive-Compulsive streak twitching :-) and agree a second aggregate repo would be over kill and wouldn;t provide much benefit as everyone would still need to work off dev. – Eoin Campbell Dec 13 '11 at 10:54
  • rather than a separate repo, why not a development branch and then controlled merges of tested, working code to the trunk? – Joseph Stine Dec 13 '11 at 17:24
  • Yes indeed, that's a better solution than two repos. – JB Nizet Dec 13 '11 at 17:36
2

Subversion records everything and until version 1.8 comes along (maybe) there's no way to erase the past. That is, unless you want to do a dump, filter, and load to remove those transactions, then to manually redo them as single transaction.

There's no real way of preventing a developer from branching in the middle, but you can change the svn:log revision property (which is the commit message) to include a statement not to use this revision as a branch point (and then point them to the good revision). That way, a developer searching for a point where to branch will be warned.

To change the revision property, you need to enable the pre-revprop-change hook to allow you to change the svn:log revprop, but it's not difficult to do. I usually set it, so the user who did the commit (svn:author) and admins (you) can modify the svn:log property anyway. This way, when someone tells me they goofed in their commit message (wrong Jira ticket, etc.), I can tell them to correct it themselves and to stop bothering me when I'm busy playing Angry Birds.

David W.
  • 105,218
  • 39
  • 216
  • 337