[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-issues
Subject:    [Issue 516]  svn obliterate
From:       Julian Foad <julianfoad () btopenworld ! com>
Date:       2009-04-28 15:37:20
Message-ID: 20090428153720.B54CC7B0D97 () sc157-tigr ! sjc ! collab ! net
[Download RAW message or body]

http://subversion.tigris.org/issues/show_bug.cgi?id=516






------- Additional comments from julianfoad@tigris.org Tue Apr 28 08:37:17 -0700 2009 -------
SUMMARY OF POINTS RAISED SO FAR

I have compiled the following list of all the significant points, from a feature
design perspective, that have been tracked in this issue so far.

I am not judging what has been said, only providing a quick reference to it. I
am not including what's been said in email and elsewhere. It is not a
comprehensive index to all comments, and people's names are given in brackets to
assist in finding an original comment and not to indicate credit for the ideas.


OBLITERATE WHAT?

  a. A node-rev. (Possible restriction: and all copies thereof [SDaugherty].)

  b. A node through all revisions. (Including all copies thereof? Just along a
single segment of its history? A path rather than a node?)

  c. A whole revision. (Possible restriction: and all subsequent revisions.)

  d. A patch. "Replay patches" onto a reverted state of the repos [BBehlendorf].


REASONS

* "Security" - delete sensitive data that was accidentally committed.

  a. From view by svn clients.

  b. From view by server admins.

This need, especially (a), is time-critical. "Better ... for all revisions of a
file to be temporarily unavailable than to unnecessarily delay removal"
[SDaugherty].

* "Maintenance" - delete large data that is no longer necessary, to save disk
space on the server.

  a. Delete large files that were accidentally committed [JRobbins, WHartshorn].

  b. Delete intermediate revisions of a sequence of changes that is no longer
interesting in detail, leaving only a few significant revisions [THarning].

  c. Delete old revisions of large files that are routinely committed but only
required for a short while (one or a few revisions) [BTutt, BWebster, ABarbati].

  d. Splitting the repository - moving certain projects, branches, tags, etc. to
another repository [KBenton].


ON-LINE/OFF-LINE

  * client-side (e.g. in "svn")

  * server-side (e.g. in "svnadmin")

"You'd add it to libsvn_ra if you could." [BTutt]. Complexity of re-deltifying
and existing WCs referring to invalid "node ids" [BCollins-Sussman]. "Remove the
node contents and mark the node 'dead' (a new state)..." [BCibej]

"SVN is a client/server app. Why shouldn't I be able to remotely administer it?"
[BTutt]

"We can & should do it through RA." [GStein]

Dump-load approach: repos down-time, and slow.

Client-side approach "is a security concern" [SDaugherty].

Should be client-side because a system's "admin cost" is a significant concern
[TRupert].


METADATA (REV-NUMS AND REV-PROPS)

"Leaving a log entry for the obliteration should be at the obliterator's
discretion; without a log entry, all trace of the path can (should? or yet
another option?) be wiped" [TTrias]. I'm not sure if this refers to creating a
new rev with a log message, or what.

Revision numbers - keep even if the revision is empty, or renumber subsequent
revisions [Talden]?


EFFECT ON CLIENT; WC INTEGRITY

Let the files left in place, but content replaced with an explanatory message
[JRobbins].

"Erase all revisions from the faulty one onwards - and let clients sort
themselves out manually" [BBucksch].

To detect brokenness, WC could store and compare "time of last obliteration"
[JSimlovic].


OPTIONAL FUNCTIONALITY

* Dump what's being obliterated [SDaugherty].


WHAT CAN SVNDUMPFILTER DO ALREADY?

  a. NOT handle moves between excluded and included sections of the repository
[JeffC]?


DUPLICATE/RELATED ISSUES IN TRACKER

#1260 - wanting 'obliterate' for server disk space recovery.
#1848 - unrelated, not really a dup.


PEOPLE WHO WERE POTENTIALLY OFFERING FUNDING

Tim Jackson
Brent Webster
Auriel Manolson
Niels Keurentjes


PEOPLE WHO WERE SPECIFYING/DESIGNING

Juraj Simlovic
Karl Fogel
Magnus Torfason


SEE ALSO

(Gone -
<http://svn.collab.net/repos/svn/trunk/contrib/server-side/svn-obliterate.py>.)

Blog/rant:
<http://blogs.quintor.nl/bbottema/2008/03/01/subversion-obliterate-the-forgotten-feature/>

Implementation proposal email (KFogel):
<http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=137319>

Functional spec in trunk:
<http://svn.collab.net/repos/svn/trunk/notes/obliterate/obliterate-functional-spec.txt>.

Design email (MTorfason):
<http://www.nabble.com/svn-obliterate:-The-four-types-of-obliteration-td22229950.html>

Investigative email (MTorfason):
<http://svn.haxx.se/dev/archive-2009-02/0642.shtml>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=463&dsMessageId=1964881

To unsubscribe from this discussion, e-mail: [issues-unsubscribe@subversion.tigris.org].
[prev in list] [next in list] [prev in thread] [next in thread]