0

I'm trying to roll back a subversion repository, that I've made a few errors in.

I would like to roll back the entire repository to a 'good version'.

The normal method to do this is:

svn merge -rHEAD:<good rev> .
svn commit -m 'roll back to <good rev>'

however, as I've got some externals in the repository, subversion won't let me complete the merge operation, without all sorts of errors.

I've managed to actually fix this using the following steps:

svn propedit svn:externals .  # delete all the externals from this file
rm -rf <list of dirs that are marked externally> #Note - Unix RM here, not subversion
svn merge -rHEAD:<good rev> .
svn resolved . # to fix the conflicts that I have on the properties in the current folder
svn commit -m 'completed long winded rollback to earlier rev'

But there has to be a better way? Anyone know of it?

P.S. Please don't say 'don't use externals' unless you've a way of multiple projects editing the same library that is in a state of flux. Externals work for me (mostly).

will
  • 71
  • 6
  • 1
    Read at least once how to perform reverse-merge in **proper way**!!! Your merge command is damned nightmare at least **twice** http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo – Lazy Badger Aug 12 '13 at 17:54
  • Apologies for not checking what was printed, but my angle-bracketted revision numbers were commented out, and the formatting was rubbish. I've edited this now. As I understand it this follows the svnbook. If it doesn't could you please be a little more explicit in where my errors are. – will Aug 13 '13 at 19:00
  • well, now syntax **is** correct. Anyway, I can't imagine a lot of (tree?) errors even in such reverse-merge case, please, show real repository `ls` and merge-output (or publish REPO-URL with RO access). You can also test reverse-merges with `--dry-run` and inspect "problematic" revisions only – Lazy Badger Aug 14 '13 at 08:59
  • Reason 781,123,456,342 why svn:externals should be avoided. – thekbb Aug 14 '13 at 15:23
  • Looking at the dry-run output, it appears the problem is that a folder has been changed from an internal to an external (once a library becomes required by multiple projects I do this - move to a global library area, remove from the local area, and add as an external), and rolling back does not remove the external prior to adding the internal, and causing a clash this way. – will Aug 15 '13 at 14:13

0 Answers0