几年来，我一直在等待 Subversion 提供“永久删除”（消除）功能。我犹豫是否要过渡到 Subversion（来自 Visual SourceSafe :p），因为我认为这是一个必不可少的功能，否则我希望存储库会不断增长。但是，由于某种原因，该功能一次又一次地被推迟。因此，我开始想知道是否还有其他一些功能或解决方法使 obliterate 功能变得可有可无。
当你想收缩 SVN 中央存储库时，你会怎么做？
示例 1：我检查了一个大型第三方库，几周后我意识到它不适合我的需要。我不希望它永远存储和备份大量数据。
示例 2：我在存储库中有 10 个大型第三方库的 10 个版本，但我只使用最新版本。
示例 3：我不小心签入了敏感信息（如John所建议的）。
示例 4：我不小心签入了一些本不打算放入存储库的大文件。
在Apache Subversion 站点上有大量svn obliterate关于问题单的讨论，其中大部分都在 2008 年左右结束。似乎普遍认为拥有它是一种很好的能力，尽管它应该很少使用。
想要它有两个主要原因。
首先，检查机密信息可能是一个问题。将其保留在那里并删除不一定是一种选择，具体取决于存储库的机密性和暴露程度。
其次，签入大量不应签入的内容会大大增加存储库的大小。如今，磁盘空间通常很便宜，但它不是无限的，而且还有其他方式文件空间也很重要。如果有必要通过网络连接发送存储库，那就是额外的时间，这可能很重要，也可能不重要。能够刻录包含整个存储库的 CD-ROM 或 DVD-ROM 可能具有真正的优势。
因此，这是一项有用的功能，目前通过转储、过滤和重新加载存储库来完成。根据我看到的报告，这很容易出错，可能很慢，并且需要关闭存储库。
显然，对于 Subversion 团队来说，这不是一个高优先级的功能，因为它需要很多年的时间来完成工作以提出设计并实现它。毕竟，应该很少这样做，并且有一种解决方法。然而，任何想要在 Subversion 上做大量工作的人都可以提供一个可能会（如果质量足够好）实施的补丁。
它违反了源代码控制的含义。
源代码控制就是能够恢复以前的状态。如果您永久删除文件，您将无法删除。
OTOH我不知道VSS所以我可能误解了“永久删除”
反对它的明显原因是因为开发人员认为它总体上会使 SVN 变得更糟——当你不小心删除一些东西并且你的 /trunk 丢失时，你对能够修剪不需要的东西的快乐将大大相形见绌。
FogBugz 具有完全相同的行为，在他们的情况下，我相信这完全是设计使然，保护用户免受他们自己的伤害。
Obliterate 违反了您希望拥有的版本控制原则。要么你不会节省任何空间，要么以前的标签会被破坏。如果您删除了任何文件，您将无法返回到真正的先前版本。
至于您对存储库增长的评论......任何存储库都会随着时间的推移随着更改的大小线性增长。这就是源代码控制系统的全部意义所在。如果您不需要能够跟踪以前的版本，那么为什么不直接使用某个共享文件夹呢？
引用Subversion Obliterate，被遗忘的功能，问题，问题，原因和解决方案三个组成部分。既然你从解决方案的问题开始，我就从这个开始。
正如您所注意到的，没有很好的解决方案。特别是如果您正在处理大型企业存储库，因为存储库越大，解决方案就越难。有一个称为转储/过滤器的功能，您可以通过它清除您不想要的东西的回购，但它不是那么容易使用，不快速且不依赖。
svn 团队在 2008 年之后做了一些小努力（跟随线程），以在其中获得一个消除功能，但这种努力无声无息地死去。
我在开头提到的文章实际上有一个很好的用例列表，其中需要一个删除命令，并且在516 问题线程中，开发人员实际上承认了它的优点。
唉，现在看来为时已晚；后来从未添加它的真正原因是现在几乎不可能实现它，因为它在最基本的级别上挂钩到代码（另见解决方案下的小努力链接）。
从常见问题条目：
修订是相互依赖的不可变树。从历史中删除修订会导致多米诺骨牌效应，在所有后续修订中造成混乱，并可能使所有工作副本无效。
问题是最初删除功能被忽略了，因为它不符合真正的版本控制原则。
再次来自常见问题条目：
如何从存储库的历史记录中完全删除文件？在某些特殊情况下，您可能想要销毁文件或提交的所有证据。（也许有人不小心提交了一份机密文件。）这并不容易，因为 Subversion 被刻意设计为永远不会丢失信息。
我已经为很多客户与更大的团队和更大的项目合作过，基本上从来没有遇到过真正的问题。是的，提到的用例保证了一个消除功能，但到目前为止，我不相信这是一个你在任何地方都会一遍又一遍地遇到的问题。当然，这个特殊问题的本质是你只需要犯一次错误，而且它不能被正确地撤消。
可以通过转储和加载来减小 SVN 存储库的大小。本质上，如果您说您永远不想恢复到超过几年的内容，则可以转储存储库，根据时间进行过滤，然后重新加载转储。由于大小而想要删除单个文件可能表明该文件最初并不真正属于源代码控制系统。
有一些脚本可以帮助您删除数据。关注此邮件列表线程以获取更多信息。
这是一种很难做到的方法，因为版本控制的本质是不丢失数据，而不是永久删除它。但如果你每年修剪一次或类似的事情，它就可以完成。
因为从存储库中删除数据打破了源代码控制的基本前提，即可以重现所有以前的状态和对源代码树的更改。如果您想从版本控制中删除某些内容，正如他们所说，您可能“做错了”。
我使用各种版本控制系统大约 15 年了，从来不需要这样的功能。
我想知道您想要该功能的原因是什么：
源代码控制的全部意义在于对存储库的外观有完整的历史记录。该obliterate命令破坏了源代码控制的这一目的，并且在所有具有它的版本控制系统中都是一个错误功能。
SVN 具有廉价的复制和廉价的分支，不需要文件的完整副本——只需更改的位。它的中央存储库通常在大小上非常易于管理，因此没有必要使用这种错误功能。
最后我检查它是作为一个 ADMIN 功能，管理员已经可以转储/过滤/broken_workaround 并删除历史记录。关于审计跟踪，这不会改变当前的引用。如果绝对必须删除某些东西，它会变得不那么可怕。
Svnadmin obliterate 是最受欢迎的功能之一，开发人员终于承认它应该存在（终于！8 年后！！！）。而且它的宣传不存在，正在将用户从 SVN 中赶走。
不幸的是，我不得不以艰难的方式了解这个“缺失的功能”。从什么时候开始基本功能成为一种特性？新用户开始听说这一点并避免使用 SVN。至于我，我现在使用 Git。
不喜欢我的意见？Linus 将 SVN 开发人员称为白痴，整个中心化系统存在缺陷。我相信 Linus 是一位真正的专家，尤其是他知道来源。
Obliterate 并不是 Subversion 的本质特性，因为它实际上打破了版本控制的基本原则（即：记录所有历史）。
而且它不是一个必不可少的功能，因为无论如何都有解决方法来完成这项工作（使用 svnadmin 和过滤）。
此外，该功能目前正在大力开发。有关详细信息，请参阅此帖子。
我做什么 - 不使用颠覆。对不起。
他们（开发人员）显然不同意您对这是一个关键特性的评估。目前并没有阻止我工作的公司使用它；）出于这个确切原因，我个人排除了颠覆。