A reverse merge should work. However, it's not entirely clear what you
want. Are "r131" and "r132" just sample revision numbers? Is your goal
simply to "go back in time and fix r111 before r112-130 were added?"
A) To create a branch that looks like: r111 -> r112 -> ... r130 ->
"r111+fix" -> "r112:r130 merge plus r130 fix"
1. Create a new workspace: svn checkout SVN_URL
2. Rollback your workspace to r111.
svn merge -r 130:112 SVN_URL
You may need to tweak "-r 130:112", I can never remember how SVN rounds
revision ranges.
3. Fix the bug in 111
4. Check-in which creates r131 which is r111 plus the bug fix. (r112:130
are removed)
5. Now re-add the changes you removed from step 2.
svn merge -r 112:130 .
6. fix the r130 bug
7. svn check-in which creates r132, which contains r111, the bug fix, and
revisions 112 through 130.
The branch looks like: r111 -> r112 -> ... -> r130 -> r131 (r111 fix, no
r112-130) -> r132 (re-added r112-130, added r130 bug fix)
The downsides are that r132 contains both the r130 fix and the r112-130
changes, and that your branch is no longer a smooth linear progression.
To create a test branch.
1. svn copy SVN_URL_at_111 BRANCH_URL
2. svn co BRANCH_URl
3. Copy a few revisions up:
svn merge SVN_URL_at_115
svn ci
svn merge SVN_URL_at_120
svn ci
svn merge SVN_URL_at_125
svn ci
svn merge SVN_URL_at_130
svn ci
4. Test the reverse merge process on the branch.
B) If revision numbers aren't important, then you can swap out the trunk
branch. The following will (should) create a branch line that looks like:
r111 -> r111 fix -> original r112-130 -> r130 fix
1. Branch from trunk-r111 (which creates r131)
2. Fix r111 on branch
3. Check in, creating r132 on branch
4. merge -r112:130 from trunk into the branch
5. check in the branch, creating r133
6. delete the trunk branch (creating r134)
7. rename branch to trunk. (creates r135)
8. fix "r130", creating r136.
End result is that the original r111 is now r131, the r111 fix is r132, the
original "r112:130" is now lumped into r133 and the fix to the original
"r130" is now r136. The original r112-r130 trunk revisions now only
accessible via peg revisions. You won't be able to use "svn log
--stop-on-copy" either.
This has the advantage of a linearly progressing line, but the check-in
times and other meta-data are changed.
Also, if you want to keep r112-130 as individual revisions, you can merge
them one at a time in step 4: merge -r trunk_at_112, check-in, merge -r
trunk_at_113, check-in, ... merge -r trunk_at_130
C) Again if revision numbers aren't important, this is a slight variation
on A above, producing: r111 -> r112 -> ... -> r130 -> r131 (r111 fix
without r112:130) -> r132 (contains r112-130 merge) -> r133 (contains r130
fix)
1. checkout trunk
2. Reverse merge: merge -r 112:130, which puts you back to r111
3. Add r111 fix
4. checkin
5. merge in r112:130 either as individual merges or as one big merge
6. check-in
7. add R130 fix
8. check-in.
There are other variations you can do (such as deleting trunk and
completely rebuilding it), but either a reverse merge to rollback to r111
or a branch off of r111 are the key strategies.
On Friday, March 8, 2013 10:06:32 AM UTC-5, frame wrote:
>
> ALL:
>
> Let's say my project head is r130. We found a bug, started in r111. I want
> to do this: I want to fix r111, check in as r131. I also want to fix r130,
> checking as r132, the new head. How to do that?
>
> Please don't criticize me on why not just fix r130 to become r131, the new
> head. Please just help on how to achieve what I want.
>
> I think revert is somehow related, so I put it on the subject, since I
> don't know how to summarize my question.
>
> Thank you for your help.
>
Received on 2013-03-11 23:24:08 CET