4

This question was originally active within the years 2009-2013 with various examples:

and so on.

Currently, all sources point to a terrible solution:

Now, the solution wouldn't be that terrible if it was only something like:

  1. Do a dump to a file.
  2. Filter files to delete:

svndumpfilter exclude file_name_needs_to_be_removed.txt --drop-empty-revs --renumber-revs < source.dump > result.dump

  1. Load filtered dump file into a new repo directory.

But when you use SVN renames, branches, etc, you need to track ALL the dependencies and the --drop-empty-revs --renumber-revs.

So now we are in 2016 Q3, with Debian having SVN 1.8. Are there any new solutions that came to light?

Community
  • 1
  • 1
Infogeek
  • 93
  • 1
  • 8
  • 3
    Any chance you could make this sound less like a pure rant? – Filburt Aug 30 '16 at 08:25
  • Using `--drop-empty-revs --renumber-revs` is a bad idea because you'll shift the revision numbers. It's better to leave a padding revision with log message `Removed by filtering` as `svndumpfilter` does by default. – bahrep Aug 30 '16 at 11:21

2 Answers2

4

I'll expand on Lazy Badger's answer with some references.

The SVN Group refers to this feature as "obliterate". Knowing this helps us dig up some more information about it.

To start with, here is the SVN group's JIRA issue about supporting obliteration. It was opened in 2001 (!) and has generated a lot of discussion both for and against implementing it. The last comment by a project committer on this issue indicates he made some progress on it, and also points us towards a milestones/feature status page.

The development notes for this feature have not been touched in some time:

>svn ls http://svn.apache.org/repos/asf/subversion/trunk/notes/obliterate/ -v
1398429 stefan2               Oct 15  2012 ./
 878962 julianfo          872 Aug 20  2009 README
 952192 rhuijben         5175 Jun 07  2010 comparison.txt
1398429 stefan2          2488 Oct 15  2012 design-audit.html
1398429 stefan2          3839 Oct 15  2012 design-authz.html
1398429 stefan2         18664 Oct 15  2012 design-repos.html
1398429 stefan2          2500 Oct 15  2012 design-wc.html
 952192 rhuijben              Jun 07  2010 fspec-cc1/
 883799 julianfo              Nov 24  2009 fspec-dd1/
 952192 rhuijben         7742 Jun 07  2010 high-level-design.txt
 904301 neels                 Jan 28  2010 hooks/
 876577 hwright         39780 Mar 12  2009 obliterate-functional-spec.txt
1398429 stefan2          7541 Oct 15  2012 plan-milestones.html
 880336 julianfo              Oct 28  2009 presentations/
 952192 rhuijben        11266 Jun 07  2010 req-spec.txt
 887471 julianfo       290129 Dec 04  2009 schema-bdb-dd1-after.svg
 887471 julianfo       297789 Dec 04  2009 schema-bdb-dd1-before.svg

Note: The last "real" commit was r906520 (Feb 4 2010); others after that were repository maintenance-related.

On the developer's mailing list, the word "obliterate" hasn't been uttered since 2014, and that was a parenthetical reference to it as an external tool:

It is perfectly reasonable to expect repair, analysis and offline filtering (obliterate) tools to access FSFS on-disk data.

Clunky work-arounds do exist, primarily revolving around the use of svn-dumpfilter. Though for most, dumping and importing the repository for something that could happen often is a non-starter.

Because it is on the roadmap, I wouldn't go as far to say that it will never be implemented. But, because (as Lazy Badger mentioned) permanent deletion of content flies in the face of Subversion's original design and purpose, it's implementation could be a long and difficult process.

Please keep in mind the standard OSS disclaimer: this project is mostly made up of individuals who contribute to it in their spare time. There are other features/fixes that have higher priority than this, so if you'd like to change that, let the developers know.

Patrick Quirk
  • 23,334
  • 2
  • 57
  • 88
-4

Short answer

No, and will not be in future

Longer answer

"Never lose data" and "history is immutable" (commited once - committed forever) is base, core principles of SVN, thus - manipulation of history and content must be hard unobvious dirty hacks&tricks, not embedded "feature". You have to:

  • think
  • before commit
Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
  • 2
    Also quite ignorant of the ways files squirreled away somewhere can become unintentionally massive (think logs, or in my case, a "settings" archive that unintentionally included a whole bunch of solr collections). – dcoli Mar 31 '18 at 14:56
  • Belated response but there are cases where it would make sense to remove files from an SVN repository. Restructuring an repository springs to mind where you want to break up a single SVN repository into multiple ones. It should not be a decision taken lightly but having something like obliterate would help in some cases. – Graymatter Aug 05 '22 at 22:21