If the bug fixes you made in r1157
are independent of the new feature you originally added in r1155
, you can try merging the changeset for the new feature back into trunk like this:
svn merge -c 1155 TRUNK_URL WORKING_COPY_PATH
This takes the differences between r1154
and r1155
and tries to apply them on top of r1157
(assuming your working copy is up to date).
Alternatively, you can try to "undo the undo" by reverse merging the changeset that removed the new feature:
svn merge -c -1156 TRUNK_URL WORKING_COPY_PATH
This takes the differences between r1156
and r1155
and tries to apply them on top of r1157
(assuming your working copy is up to date). The minus sign in -1156
is critical because it indicates that this is a reverse merge.
Note that this does not actually remove r1156
. Nor are you "restoring" the repository to an earlier revision. r1156
was already committed, so it will stay in the repository forever, and HEAD
will never point to r1156
again. You are simply applying the same changes as were made in that revision, but in reverse order, to your working copy. This is a critical point that you need to understand when doing merges in SVN.
Either way, if you touched the same bits of code in your bug fixes and in the new feature, you may get merge conflicts, which you will have to resolve manually. When you have resolved all conflicts, you now have to commit your changes to your working copy:
svn commit WORKING_COPY_PATH
Now HEAD
will be at r1158
and both your bug fixes and your new feature will be there.