|
我们刚刚在一周前重建了所有的回购,今天我们已经接近那一点了.我需要弄清楚为什么会这种情况发生……
$hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
smartdox/application/helpers/common_helper.php@?: rev 1 points to unexpected changeset 10
(expected )
smartdox/application/helpers/common_helper.php@?: fbe7ec6785e5 not in manifests
smartdox/application/libraries/MY_Model.php@?: rev 1 points to unexpected changeset 10
(expected )
smartdox/application/libraries/MY_Model.php@?: d84e95aff93f not in manifests
smartdox/application/product_customizers/Proposals - CA Integrated/product.php@?: rev 1 points to unexpected changeset 2
(expected 7)
smartdox/application/product_customizers/Proposals - CA Specialty/custom.js@?: rev 1 points to unexpected changeset 2
(expected 7)
smartdox/application/product_customizers/Proposals - CA Specialty/product.php@?: rev 1 points to unexpected changeset 2
(expected 7)
smartdox/application/product_customizers/Proposals - GA Integrated/product.php@?: rev 1 points to unexpected changeset 2
(expected 7)
smartdox/application/product_customizers/Proposals - NY Combined/custom.js@?: rev 1 points to unexpected changeset 5
(expected 10)
smartdox/application/product_customizers/Proposals - NY Combined/custom.js@?: rev 2 points to unexpected changeset 6
(expected 12)
smartdox/application/product_customizers/Proposals - NY Combined/product.php@?: rev 1 points to unexpected changeset 2
(expected 7)
smartdox/application/views/help/training.php@?: rev 1 points to unexpected changeset 7
(expected 6)
smartdox/css/admin.css@?: rev 1 points to nonexistent changeset 26
(expected )
smartdox/css/admin.css@?: 5c92b2914085 not in manifests
我知道我们需要重新创建回购,但我需要确定问题的实际来源,所以我知道为什么会这样.有人对我如何调查/解决这些问题有任何想法？ https://www./wiki/RepositoryCorruption并没有像我希望的那样有用……它没有概述rev x指向意外变化x的情况x
似乎Mercurial应该是事务性的,因此绝不允许我们破坏我们的存储库,除非我们进入并手动删除文件.
UPDATE
我们认为桑巴舞是个问题.我们使用它来映射Windows上的Linux驱动器,以便我们可以使用Tortoise HG.我们正在提出替代解决方案. 解决方法: 这在正常使用中从未发生过.大多数网站都有回收多年没有看到hg验证说出来的事情.
我见过这种情况的唯一一次是由以下原因造成的：
>人们过于积极地删除文件.例如：找到. -name’* .bak’| xargs rm.这看起来非常安全,但它会在repo / .hg / store中删除文件,这是一个无用户去区域
>人们过于积极地修改文件.例如,找到repo -type f | xargs perl -pie’s / 1999/2000′.感觉就像你在工作目录中的所有文件中将1999更改为2000,但是你再次包含了repo / .hg / store,现在你的文件已经损坏了
>人们使用除hg推送,拉取和克隆之外的任何机制来将更改或更改集从一台计算机移动到另一台计算机.
最后一个值得另一个清单.其中任何一个都是可疑的：
>在本地计算机上运行hg的文件服务器(尤其是windows / smb)上的repo
> .hg目录的Dropbox式同步
当您在远程文件服务器上的存储库上执行操作时,Mercurial作者非常难以保持正确,但文件服务器协议原语并不存在.例如,hg clone创建NTFS支持的硬链接,在本地系统上,get-link-count调用返回当前数字,即使它大于1,但是当Windows客户端通过smb查询NTFS主机文件的某些版本时Windows总是返回1的链接数,这告诉mercurial没有其他克隆正在使用该文件,因此可以在不先复制的情况下对其进行修改.
我认为最后一个已经在Mercurial中得到了解决,但潜在的必要性是,如果“更改”正在通过推送,拉动或克隆以外的任何命令启动的网络电缆进行,那么你就会遇到麻烦,你需要拥抱DVCS的分布式特性并拥有一个真正的本地克隆.
如果您的损坏既不是由过于宽泛的递归命令引起的,也不是由文件服务器无意义引起的,那么这是我以前没见过的. 来源：http://www./content-3-247251.html
|
