当您想要缩小SVN中央存储库时,您会怎么做?
示例1:我检入了一个大型第三方库,几周后我意识到它不适合我的需求。我不想永远存储和备份那么大量的数据。
示例2:我在存储库中有10个版本的10个大型第三方库,但我只使用最新版本。
示例3:我不小心检入了敏感信息(如John建议的)。
示例4:我不小心检入了一些从未打算放入存储库的大文件。
在Apache Subversion网站的问题票据中,有不少关于svn obliterate
的讨论,大部分讨论发生在2008年左右。人们普遍认为它是一个很好的功能,但使用应该很少。
想要这个功能主要有两个原因。
首先,检入机密信息可能会成为问题。将其删除并保留在其中并不一定是一种选择,这取决于存储库的保密级别和曝光程度。
其次,检入大量不应检入的内容可能会极大地增加存储库的大小。虽然现在磁盘空间通常很便宜,但它并不是无限的,文件空间对应用也有其他影响。如果需要通过网络发送存储库,则需要额外的时间,这可能很重要,也可能不重要。能够将整个存储库刻录到CD-ROM或DVD-ROM中实际上有很多优势。
因此,这是一个有用的功能,目前可以通过转储、过滤和重新加载存储库来实现。根据我看到的报告,这很容易出错,可能很慢,并且需要关闭存储库。
显然,这不是Subversion团队的高优先级功能,因为很多年来需要的是有人进行设计和实现工作。毕竟,它应该很少使用,并且有解决方法。但是,任何想要在Subversion上大量工作的人都可以提供补丁,如果质量足够好,则可能会被实现。
它违反了源代码控制的意义。
源代码控制的意义在于能够恢复之前的状态。如果您永久删除一个文件,您将无法恢复该文件。
但是,我不了解VSS,因此我可能对“永久删除”有所误解。
正如您所注意到的,没有很好的解决方案。特别是如果您正在处理一个大型公司存储库,因为解决方案随着存储库的增大而变得更加困难。有一个名为dump / filter的功能,通过它可以清除您不需要的存储库内容,但它并不容易使用,也不快速和可靠。
在2008年后,svn小组曾经有过一次小小的努力(请参考该帖子),试图将一个消除功能添加到其中,但这项工作默默结束了。
我在开头提到的文章实际上列出了需要使用消除命令的一些用例,在516问题帖子中,开发人员实际上承认了它的价值。
遗憾的是,现在似乎为时已晚;真正的原因是它现在几乎不可能实现,因为它在最基本的级别上连接到代码(还请参见“解决方案”下的小小的努力链接)。
从FAQ条目中得知:
修订版本是互相建立的不可变树。从历史记录中删除一个修订版本将引起连锁反应,在所有后续修订版本中创建混乱,并可能使所有工作副本无效。
问题在于最初消除功能被视为不符合真正版本控制的原则。
再次从FAQ条目中得知:
如何完全从存储库历史记录中删除文件? 有一些特殊情况,您可能需要销毁文件或提交的所有证据。(也许有人不小心提交了机密文件。)这并不容易,因为Subversion的设计是绝对不会丢失信息的。
我已经为很多客户使用SVN,处理过包含更大团队和项目的工作,基本上从来没有真正的问题。是的,提到的使用案例需要一个完全删除功能,但到目前为止,我并不认为这是到处都会遇到的问题。当然,这个特殊问题的性质是你只需要犯一次错误,就无法正确地撤销。
通过转储和加载,可以缩小SVN存储库的大小。如果您从未想过要恢复两年前的内容,则可以转储存储库,基于时间进行过滤,然后重新加载转储数据。由于文件大小过大而想要摆脱单个文件可能表明该文件实际上并不属于源代码控制系统。
从仓库中删除数据会破坏源代码控制的基本前提,即可以重现源代码树的所有先前状态和更改。如果您想要从版本控制中消除某些内容,则可能是“做错了”,正如他们所说。
有一些脚本可以帮助您彻底删除数据。请参阅此邮件列表线程了解更多信息。
这是一种较为困难的方法,因为版本控制的本质在于不丢失数据,而不是永久删除数据。但如果您每年修剪一次或类似的操作,那么是可以做到的。
我使用各种版本控制系统已经有15年了,从未需要过这样的功能。
我想知道你想要这个功能的原因: