[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: a svn revert question

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Sat, 9 Mar 2013 08:45:22 -0500

On Fri, Mar 8, 2013 at 10:04 PM, Ryan Schmidt
<subversion-2012c_at_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.
Received on 2013-03-09 14:46:35 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.