为什么在Subversion中,彻底删除(obliterate)不是一个必要的功能?

20
多年来,我一直在等待Subversion添加“永久删除”(抹去)功能。我犹豫是否要从Visual SourceSafe转换到Subversion,因为我认为这是一个必要的功能,否则我会期望存储库不断增长。然而,由于某种原因,该功能一次又一次地被推迟。因此,我开始想知道是否有其他功能或解决方法可以使抹去功能变得不必要。
当您想要缩小SVN中央存储库时,您会怎么做?
示例1:我检入了一个大型第三方库,几周后我意识到它不适合我的需求。我不想永远存储和备份那么大量的数据。
示例2:我在存储库中有10个版本的10个大型第三方库,但我只使用最新版本。
示例3:我不小心检入了敏感信息(如John建议的)。
示例4:我不小心检入了一些从未打算放入存储库的大文件。

7
我认为磁盘空间不是问题,但出于其他原因需要删除文件。 - Mr. Boy
4
想象一下,有人意外地提交了非常机密的数据。Subversion用户能做什么?什么也做不了!这些信息将永久保存在你的代码库中 x-D。 - codymanix
4
除了系统管理员通过转储,过滤和恢复存储库之外,不能撤消签入。我不希望常规用户可以使用“彻底删除”功能,但管理员可以使用该功能会很好。 - David Thornley
8
关于您的问题"What do you do when you want to shrink the SVN central repository?"...我的公司做法是:让存储库服务器崩溃,没有备份。这是使存储库变小的最佳方法,也很好地遵循了 obliterate 原则。 - user253984
3
本地磁盘空间可能相对便宜。但是当公司需要每周进行灾难恢复备份时,这种空间会急剧增加。我们需要4份备份加上每周7天的备份。如果3D团队意外上传了一个庞大的3D模型,将会永久破坏我们备份代码库的能力! - TamusJRoyce
显示剩余11条评论
13个回答

18

Apache Subversion网站的问题票据中,有不少关于svn obliterate的讨论,大部分讨论发生在2008年左右。人们普遍认为它是一个很好的功能,但使用应该很少。

想要这个功能主要有两个原因。

首先,检入机密信息可能会成为问题。将其删除并保留在其中并不一定是一种选择,这取决于存储库的保密级别和曝光程度。

其次,检入大量不应检入的内容可能会极大地增加存储库的大小。虽然现在磁盘空间通常很便宜,但它并不是无限的,文件空间对应用也有其他影响。如果需要通过网络发送存储库,则需要额外的时间,这可能很重要,也可能不重要。能够将整个存储库刻录到CD-ROM或DVD-ROM中实际上有很多优势。

因此,这是一个有用的功能,目前可以通过转储、过滤和重新加载存储库来实现。根据我看到的报告,这很容易出错,可能很慢,并且需要关闭存储库。

显然,这不是Subversion团队的高优先级功能,因为很多年来需要的是有人进行设计和实现工作。毕竟,它应该很少使用,并且有解决方法。但是,任何想要在Subversion上大量工作的人都可以提供补丁,如果质量足够好,则可能会被实现。


2
如果您将该功能视为“撤消”而不是“删除”,用例就变得更加明显了;只需要一个经验不足的用户提交几个100 MB的 .obj/.pdb 文件。 - Mr. Boy
1
离线备份也是一个问题。如果有人上传了一个超大的文件,你的备份窗口就会被占满,这是非常麻烦的。 - Marco van de Voort

10

它违反了源代码控制的意义。
源代码控制的意义在于能够恢复之前的状态。如果您永久删除一个文件,您将无法恢复该文件。

但是,我不了解VSS,因此我可能对“永久删除”有所误解。


9
如果您意外泄露了一些个人数据,比如让所有开发人员看到彼此的评估评论或薪资,这在某些情况下可能是非法的。您该怎么办? - Mr. Boy
2
@John:请向管理员请求删除它(这是可能的,也不难)。这应该是例外,而不是常规情况。如果您未能正确使用源代码控制,那么这并不是软件的错。 - user253984
2
不,根据我所听到的,你必须手动拆分该代码库。 - Mr. Boy
2
@dbmerlin... 如果你设计的软件故意伤害人们,以迫使他们按照你的意愿使用软件,那么你就有问题了。 - Mr. Boy
3
这个答案只是整个故事的一部分。在实际的SVN使用中,"obliterate"(删除)有其合理的使用情况需要考虑。 - usr
显示剩余10条评论

8
明显的反对理由是开发人员认为这会使SVN变得更糟——你能够修剪不需要的东西所带来的快乐将远远被你意外删除某些内容时和你的/trunk消失时所产生的愤怒所淹没。
FogBugz有完全相同的行为,在他们的情况下,我相信这是完全出于设计,保护用户免受自己的伤害。

7
Obliterate违反了您所需的版本控制原则。要么您不保存任何空间,要么以前的标签会变得不可用。如果您已经抹掉了任何文件,则无法返回到真正的先前版本。
至于您对存储库增长的评论...任何存储库都会随着时间的推移与更改的大小成线性增长。这就是源代码控制系统的全部意义。如果您不需要能够跟踪先前的版本,那为什么不只是坚持在某个共享文件夹中?

5
回到“.old”、“ .older”、“.oldest”、“.bak”、“.backup”、“.deleted”、“.obsolete”和“~”的黄金时代吧,那些都是过去的日子,感觉就像昨天。我仍然偶尔会做恶梦…… - user253984

7
引用Subversion Obliterate, the forgotten feature中提到的问题有三个组成部分,即问题原因解决方案。既然您从问题转向解决方案,那我就从那里开始。

解决方案

正如您所注意到的,没有很好的解决方案。特别是如果您正在处理一个大型公司存储库,因为解决方案随着存储库的增大而变得更加困难。有一个名为dump / filter的功能,通过它可以清除您不需要的存储库内容,但它并不容易使用,也不快速和可靠。

在2008年后,svn小组曾经有过一次小小的努力(请参考该帖子),试图将一个消除功能添加到其中,但这项工作默默结束了。

问题

我在开头提到的文章实际上列出了需要使用消除命令的一些用例,在516问题帖子中,开发人员实际上承认了它的价值。

遗憾的是,现在似乎为时已晚;真正的原因是它现在几乎不可能实现,因为它在最基本的级别上连接到代码(还请参见“解决方案”下的小小的努力链接)。

FAQ条目中得知:

修订版本是互相建立的不可变树。从历史记录中删除一个修订版本将引起连锁反应,在所有后续修订版本中创建混乱,并可能使所有工作副本无效。

原因

问题在于最初消除功能被视为不符合真正版本控制的原则。

再次从FAQ条目中得知:

如何完全从存储库历史记录中删除文件? 有一些特殊情况,您可能需要销毁文件或提交的所有证据。(也许有人不小心提交了机密文件。)这并不容易,因为Subversion的设计是绝对不会丢失信息的

然而

我已经为很多客户使用SVN,处理过包含更大团队和项目的工作,基本上从来没有真正的问题。是的,提到的使用案例需要一个完全删除功能,但到目前为止,我并不认为这是到处都会遇到的问题。当然,这个特殊问题的性质是你只需要犯一次错误,就无法正确地撤销。


5

通过转储和加载,可以缩小SVN存储库的大小。如果您从未想过要恢复两年前的内容,则可以转储存储库,基于时间进行过滤,然后重新加载转储数据。由于文件大小过大而想要摆脱单个文件可能表明该文件实际上并不属于源代码控制系统。


1
说到这个,你为什么要将第三方库检入你的代码库呢?如果你非常需要保留它们在你的系统中,可以为第三方库建立一个单独的代码库,并使用“externals”将其链接到你的源代码树中。 - bta

4

从仓库中删除数据会破坏源代码控制的基本前提,即可以重现源代码树的所有先前状态和更改。如果您想要从版本控制中消除某些内容,则可能是“做错了”,正如他们所说。


4

有一些脚本可以帮助您彻底删除数据。请参阅此邮件列表线程了解更多信息。

这是一种较为困难的方法,因为版本控制的本质在于不丢失数据,而不是永久删除数据。但如果您每年修剪一次或类似的操作,那么是可以做到的。


你能否给出这种操作通常需要多长时间的估计? - Dimitri C.
不完全是,但它涉及修改表格,然后转储并读取存储库。所以它不会快速完成,但可能是自动化的。 - extraneon

3
整个源代码控制的目的是要有完整的历史记录,记录仓库的变化。 obliterate 命令违背了源代码控制的初衷,它是所有版本控制系统中一个不良功能。SVN 具备快速复制和分支功能,不需要完全复制文件,只需复制更改的位。其中央仓库通常很小,因此这个不良功能是不必要的。

1
另一方面,“这是我的该死的代码库,我应该可以随心所欲地做任何事情”的论点如何?软件是否应该为您做出决定呢? - Mr. Boy
2
@John:但很可能这不是你自己的代码库,而是和其他人共享的。这些人需要确保版本X就是版本X。你当然可以Fork SVN并给它另一个名称,但人们可能更喜欢“安全”的版本。 - Otto Allmendinger
1
其他人会按照我的指示去做的 ;) - Mr. Boy
您可以通过以管理员身份登录svn服务器并在存储库本身中进行一些小动作来永久删除文件。 - JSBձոգչ
1
虽然这样做并不是一个好的方式。我知道开源社区的人不太关注好的用户界面,但是必须摧毁仓库并把它拆开有点过了 :) - Mr. Boy

3

我使用各种版本控制系统已经有15年了,从未需要过这样的功能。

我想知道你想要这个功能的原因:

  • 磁盘空间?难以置信,考虑到磁盘空间的价格
  • 将密码提交到版本控制?那就教训你了。赶紧去改密码
  • 仓库速度?听起来不像,但如果我会考虑一个完全不同的系统,它据说具有更好的性能。

5
你把所有的财务记录都提交到了一个开源系统里? - Mr. Boy
@John:“哎呀”这个词都不足以形容……;-) - T.J. Crowder
@Matthew:人都会犯错。 - Dimitri C.
2
特别是当非程序员使用SVN时,他们经常难以理解概念,即使使用可视化工具也会提交各种垃圾。 - Mr. Boy
2
我知道人犯错是很正常的。但这并不会阻止我运用我的言论自由权利,用讽刺的话语称呼他们是个白痴。(如果我做错了什么事情,比如不小心提交一个密码,我也会称呼自己是个白痴。) - Matthew Whited
在SO上你没有言论自由。我的评论在另一篇帖子中被删除,因为我说某人假定我在运行Linux是愚蠢的。 - Mr. Boy

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接