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

Re: the obliterate discussion - why dumpfiltering is no valid workaround

From: <david.x.grierson_at_jpmorgan.com>
Date: 2007-07-20 16:06:27 CEST

Thing is that other tools have it -
Toby wrote:
> On 20-Jul-07, at 10:03 AM, patrick wrote:
>> if i had just one wish it'd be a non-blocking (or very shortly
>> blocking ;-))
>> svadmin obliterate MYREPOS *.log
>I don't want to pre-empt the experts, but I think a rationale against
>such a thing can be made. For one thing it's a powerful regret-
>generator (dangerous tool, think rm -rf but on your repo(!). Typing
>error?) It -should- be hard to destroy data; a version control system
>is designed to keep it safe. It's a bit like asking for openable
>windows on a space capsule.

It would have been easier for Ripley if the window had been openable -
that way she wouldn't have had to put a hole in it.

Seriously though - other revision control systems have a similar function.
ClearCase has the "rmelem" command.

From the rmelem man-page:
    The rmelem command completely deletes one or more elements or symbolic
    links. In a snapshot view, rmelem also unloads the element from the

    This command destroys information irretrievably. Using it carelessly
    compromise your organization's ability to support old releases. In
    cases, it is better to use the rmname command.
      o Removes all references to the element from versions of the VOB's
        directory elements. (This means that subsequent listings and
        comparisons of those directory versions will be historically

Attempting to use rmelem performs 2 checks:
1) You must be the object creator or the repository owner or root.
2) You must verify after a long warning message that you want to destroy
the object.

I'm pretty sure that such a "dangerous" comamnd would have appropriate
checks and balances before it allowed the obliterate operation to


David Grierson
JPMorgan - IB Architecture - Source Code Management Consultant
GDP 228-5574 / DDI +44 141 228 5574 / Email david.x.grierson@jpmorgan.com
Sentinel House 2nd floor, 103 Waterloo Street, Glasgow G2 7BW
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates. This transmission may contain information that is
privileged, confidential, legally privileged, and/or exempt from
disclosure under applicable law. If you are not the intended
recipient, you are hereby notified that any disclosure, copying,
distribution, or use of the information contained herein (including
any reliance thereon) is STRICTLY PROHIBITED. Although this
transmission and any attachments are believed to be free of any
virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the
recipient to ensure that it is virus free and no responsibility is
accepted by JPMorgan Chase & Co., its subsidiaries and affiliates,
as applicable, for any loss or damage arising in any way from its
use. If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you. Please refer
to http://www.jpmorgan.com/pages/disclosures for disclosures
relating to UK legal entities.
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 20 16:06:09 2007

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.