为什么不删除Subversion的基本功能?

Dim*_* C. 20 svn obliterate

几年来,我正在等待Subversion具有"永久删除"(删除)功能.我对转换到Subversion(来自Visual SourceSafe:p)犹豫不决,因为我认为这是一个必不可少的功能,否则我会期望存储库不可阻挡地增长.但是,出于某种原因,该功能会一次又一次地被推迟.所以我开始想知道是否有其他功能或解决方法使得删除功能可有可无.

当你想缩小SVN中央存储库时,你会怎么做?

示例1:我检查了一个大型的第三方库,几周后我发现它不适合我的需求.我不希望它永远存储和备份大量数据.

示例2:我在存储库中有10个版本的10个大型第三方库,但我只使用最新版本.

示例3:我意外地检查了敏感信息(如John所建议的).

示例4:我不小心检查了一些从未打算放入存储库的大文件.

Dav*_*ley 19

svn obliterateApache Subversion网站上对问题单进行大量讨论,其中大部分都是在2008年左右结束.似乎普遍认为这是一个很好的能力,尽管它的使用应该很少.

想要它有两个主要原因.

首先,检查机密信息可能是个问题.将其留在那里,删除,不一定是一种选择,具体取决于保密程度和存储库的暴露程度.

其次,检查大量不应该检入的东西可以大大增加存储库的大小.磁盘空间现在通常很便宜,但它不是无限制的,文件空间还有其他方面可以解决.如果有必要通过网络连接发送存储库,那么这是额外的时间,可能重要也可能不重要.能够刻录包含整个存储库的CD-ROM或DVD-ROM可能具有真正的优势.

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

显然,对于Subversion团队来说,这不是一个高优先级的功能,因为很多年来需要的是有人做一个设计并实现它的工作.毕竟,它应该很少完成,并有一个解决方法.但是,任何想要在Subversion上做大量工作的人都可以提供一个补丁(如果质量足够好)可能会被实现.

  • 如果你认为这个特征是"undo"而不是"obliterate",那么用例就会变得更加明显; 你只需要一个没有经验的用户提交几个100Mb的.obj/.pdb文件. (2认同)

Mor*_*dur 11

它违反了源代码控制的含义.
源控制就是能够恢复以前的状态.如果您永久删除文件,则无法删除.

OTOH我不知道VSS所以我可能误解了"永久删除"

  • 如果您不小心提交了一些个人数据怎么办?比如让所有开发者看到你对彼此的评价意见或薪水?在某些情况下这可能是非法的,你做什么? (8认同)
  • 这个答案只是整个故事的一部分.真实世界的SVN用法具有必须考虑的有效使用案例. (3认同)
  • @John:要求管理员删除它(这是可能的而不是那么难).这应该是例外,而不是正常情况.如果您未能正确使用源控制,则不是软件的错误. (2认同)
  • 没有.你必须根据我的说法手动撕开回购. (2认同)
  • @dbmerlin ...如果你设计故意伤害别人的软件迫使他们按照你的意愿使用软件,你就会遇到问题 (2认同)

Mr.*_*Boy 8

反对它的明显原因是因为开发人员认为它会使SVN变得更糟 - 当你意外地删除某些内容并且你的/ trunk丢失时,你能够修剪不需要的东西所带来的快乐会因你的愤怒而相形见绌.

FogBugz具有完全相同的行为,在他们的情况下,它完全是设计我相信,保护用户自己.


Yul*_*liy 7

Obliterate违反了您希望拥有的版本控制原则.您要么不保存任何空间,要么以前的标签会被破坏.如果您删除了任何文件,您将无法返回到真正的先前版本.

至于你对存储库增长的评论......随着时间的推移,任何存储库都会随着变化的大小线性增长.这是源控制系统的重点.如果您不需要能够跟踪以前的版本,那么为什么不在某个地方粘贴共享文件夹呢?

  • 哦,是的,回到.old,.older,.oldest,.bak,.backup,.deleted,.obsolete和〜的黄金时代.那些日子......感觉就像昨天.我还有噩梦... (5认同)

Ben*_*ema 6

引用Subversion Obliterate,这个被遗忘的特征,问题有三个组成部分,问题,原因解决方案.既然你从解决方案的问题开始,我将从那开始.

正如您所注意到的,没有很好的解决方案.特别是如果你正在处理一个大型企业存储库,因为解决方案变得越来越难,repo变得越大.有一个叫做dump/filter的功能,通过它你可以清理你不想要的东西的回购,但它不是那么容易使用,不是快速而且不依赖.

在2008年之后,svn团队已经进行了一些努力(按照线程)在那里获得了一个消失的特征,但是努力死于沉默的死亡.

问题

我在开始时提到的文章实际上有一个很好的用例列表,其中一个需要一个删除命令,并且在516问题线程中,开发人员实际上承认了它的优点.

唉,现在似乎为时已晚; 它之后从未被添加的真正原因是它现在几乎不可能实现它,因为它在最基本的层面上挂钩代码(也见解决方案下的小努力链接).

FAQ条目:

修订是不可变的树,彼此建立在一起.从历史记录中删除修订版会导致多米诺骨牌效应,在所有后续修订版中产生混乱,并可能使所有工作副本无效.

原因

问题是最初的删除特征被驳回,因为它不符合真实版本控制的原则.

再次从FAQ条目:

如何从存储库的历史记录中完全删除文件?在某些特殊情况下,您可能希望销毁文件或提交的所有证据.(也许有人意外地提交了一份机密文件.)这并不容易,因为Subversion是故意设计的,永远不会丢失信息.

然而

我和很多客户一起使用SVN,现在有更大的团队和更大的项目,基本上从来没有真正的问题.是的,所提到的用例保证了一个消失的功能,但到目前为止,我不相信这是一个问题,你到处都是一遍又一遍.当然,这个特殊问题的本质是你只需要犯一次错误而且不能正常撤消.


Spa*_*arr 5

因为从存储库中删除数据会破坏源控制的基本前提,即可以重现所有先前的状态和对源树的更改.如果你想从版本控制中删除某些东西,你可能正在说"做错了".


Jen*_*der 5

我现在使用各种版本控制系统大约15年,从来不需要像这样的功能.

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

  • 光盘空间?考虑到光盘空间的价格,很难相信
  • 提交密码到版本控制?那会教你的.转到并更改密码
  • 存储库的速度?听起来不是这样,但是如果我考虑一个完全不同的系统,假设性能更好.

  • o将您的整个财务记录提交给开源系统? (5认同)
  • 特别是当非程序员使用SVN时.即使使用视觉工具,他们也经常难以掌握概念,并犯下各种垃圾. (2认同)
  • 我知道人们会犯错误.这不会阻止我以讽刺的形式使用我的言论自由,并称他们为白痴.(如果我做了这样的话,我甚至会称自己为白痴.每当我意外地检查密码时,我都会这样做.) (2认同)

tlo*_*ach 5

通过执行转储和加载可以减小SVN存储库的大小.基本上如果你说你永远不想恢复到超过几年的东西,就可以转储存储库,根据时间过滤,然后重新加载转储.由于大小而想要摆脱单个文件可能表明该文件首先并不真正属于源控制系统.


ext*_*eon 5

有一些脚本可以帮助您删除数据.请按照此邮件列表主题获取更多信息.

这是一个很难的方法,因为版本控制的本质不是丢失数据,而是永久删除它.但是,如果你每年修剪一次或类似的东西可以做到.