a svn revert question

[frame <xs...@yahoo.com>]

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.

Re: a svn revert question

[ja...@gmail.com]

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@111  BRANCH_URL
2. svn co BRANCH_URl
3. Copy a few revisions up:
svn merge SVN_URL@115
svn ci
svn merge SVN_URL@120
svn ci
svn merge SVN_URL@125
svn ci
svn merge SVN_URL@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@112, check-in, merge -r 
trunk@113, check-in, ... merge -r trunk@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.
>

Re: a svn revert question

[Nico Kadel-Garcia <nk...@gmail.com>]

On Fri, Mar 8, 2013 at 10:04 PM, Ryan Schmidt
<su...@ryandesign.com> wrote:
>
> On Mar 8, 2013, at 09:06, frame wrote:
>
>> 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.
>
> That's not how Subversion works. A revision number is just an identifier for a change made at a point in time in your repository. You can't change history. All you can do is create new history.
>
> What you're asking for is like saying a week ago you bought a sofa, and now you've realized you don't like the sofa and want to make it so that you never bought it. You can't do that; you *did* buy it. All you can do now is see if you can return the sofa for a refund, or maybe you can sell it to someone else. But nothing will change the fact that you *did* buy the sofa and *did* have it for a week.

This is also closely tied to the oft-requested "svnadmin obliterate"
feature, to remove bulky or security sensitive files accidentally
committed to Subversion, and to remove their enitire history so they
are unavailable  It's one of the most frequent feature requests for
Subversion, and it's never been safely implemented that I've ever
seen.

This is partly becuase if you did change the records, you'd be in
danger of "split-brain" opeartions where one repository is distinct
from its mirror or the files and components on old working copies
don't match the compnents of new working copies This is a very, very
dangerous practice. If you *HAVE* to do this, because for some
political reason you wish to erase traces that a revision occurred, or
you accidentally stored bulky or security sensitive files
inappropriately, you should build a new repository with the altered
history and a new repository uuid, and force clients to switch to that
one.

Re: a svn revert question

[Ryan Schmidt <su...@ryandesign.com>]

On Mar 8, 2013, at 09:06, frame wrote:

> 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.

That's not how Subversion works. A revision number is just an identifier for a change made at a point in time in your repository. You can't change history. All you can do is create new history.

What you're asking for is like saying a week ago you bought a sofa, and now you've realized you don't like the sofa and want to make it so that you never bought it. You can't do that; you *did* buy it. All you can do now is see if you can return the sofa for a refund, or maybe you can sell it to someone else. But nothing will change the fact that you *did* buy the sofa and *did* have it for a week.

So what you do now is: whatever mistake was made in r111, check out a working copy of the affected part of the repository, fix the mistake, and commit it.

Re: a svn revert question

[Thorsten Schöning <ts...@am-soft.de>]

Guten Tag frame,
am Freitag, 8. März 2013 um 16:06 schrieben Sie:

> 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?

The easiest way would not to do what you describe, but create a new
branch or tag by copying r111 to a different directory than your trunk
and fix your bug there and use that tag or branch for whatever reason
you have to fix the bug in your old revision.

Everything else is a bit more complicated as you can't commit on top
on an old revision. What you can to is revert your current work on a
file to an old revision, commit this as your new head and afterwards
fix the bug in the new head with the old source. Afterwards you need
to revert everything back to your initial head before you reverted to
the source of r111, commit and fix the bug again. You don't
necessarily need the commit between reverting the source and fixing
the bug, but with it it would be more clear what was needed to fix the
bug and is not part of the revert to fix the bug.

What you can't do is checking out r111 and commit directly on top of
this revision as you can only commit on top of head and in your case
r111 and r130 would surely differ in the same file you want to change.

This may help to understand the differences:

http://stackoverflow.com/questions/1214939/update-item-to-revision-vs-revert-to-revision

> 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.

Nevertheless it would be good to know why you need to fix your old
revision, as one could recommend best practices, like using tags and
branches for those kinds of things.

> I think revert is somehow related, so I put it on the subject,
> since I don't know how to summarize my question.

revert is the wrong command, what you have to look at is update and
merge, but as I mostly use TortoiseSVN, I can't give you an example.

http://stackoverflow.com/questions/345997/better-way-to-revert-to-a-previous-svn-revision-of-a-file

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning       E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow