DVCS和数据丢失?

时间:2009-07-24 15:13:11

标签: version-control dvcs risk-management

使用DVCS近两年之后,似乎一个固有的“缺陷”是意外数据丢失:我丢失了没有推送的代码,我也知道其他人也有。

我可以看到一些原因:非现场数据重复(即“提交必须转到远程主机”)没有内置,存储库与代码和代码的概念位于同一目录中“hack'直到你有东西要发布”很普遍......但那就是重点。

我很想知道:您是否经历过与DVCS相关的数据丢失?或者您是否一直在使用DVCS?而且,除了“记得经常推”之外,还有什么可以做的,以尽量减少风险?

3 个答案:

答案 0 :(得分:3)

我丢失了DVCS中的数据,因为删除了树和存储库(不记得它有重要信息),并且由于使用DVCS命令行(git,在特定情况下)中的错误:旨在还原我所做的更改的操作实际上已从存储库中删除了许多已提交的修订。

答案 1 :(得分:2)

我从集中式VCS中破坏未提交的更改中丢失了更多数据,然后决定我真正想要它们,而不是我用DVCS做过的任何事情。部分原因是我已经使用CVS差不多十年了,git不到一年,所以我有更多的机会遇到集中模型的问题,但是工作流之间的工作流属性存在差异。两个模型也是主要因素。

有趣的是,大多数原因归结为“因为丢弃数据更容易,我更有可能保留它,直到我确定我不想要它”。 (丢弃数据与丢失数据之间的唯一区别在于您打算丢弃数据。)最大的影响因素可能是我的工作流习惯的一个怪癖 - 当我使用DVCS时,我的“工作副本”通常是几个不同的副本传播在多台计算机上运行,​​因此单个仓库中的损坏或丢失甚至是我一直在研究的计算机上的灾难性数据丢失都不太可能破坏数据的唯一副本。 (能够做到这一点是分布式模型相对于集中式模型的一大胜利 - 当每次提交成为存储库的永久部分时,复制临时变更的心理障碍要高得多。)

就最大限度地降低风险而言,可以养成尽量减少风险的习惯,但你必须养成这些习惯。那里有两个一般原则:

  • 数据直到存在才存在 它的多个副本在不同的 地方。有工作流习惯 这会给你多份副本 免费 - 例如,如果你工作 在两个不同的地方,你会有 推到一个共同位置的理由 在每个工作会议结束时, 即使它还没有准备好发表。
  • 不要试图做任何聪明的事, 愚蠢的,或超出你的舒适区 唯一引用提交 你可能想保留。创建一个 您可以恢复的临时标记, 或者创建一个临时分支来做 上的操作。 (git的reflog允许 你恢复旧的参考后 事实;如果是其他人,我不会感到惊讶 DVCS具有类似的功能。 所以手动标记可能不是 必要的,但通常更多 反正很方便。)

答案 2 :(得分:0)

在分发和确保所有内容都“保存”之间存在固有的张力(基本的假设是保存意味着在其他地方备份)。

IMO,如果您在同一个工作线上同时在多台计算机上工作(或者更确切地说是几个存储库,这只是一个真正的问题:例如,我经常需要在同一台计算机上的多个VM之间共享更改) 。在这种情况下,“集中式”工作流程将是理想的:您将设置临时服务器,并在某些给定分支上使用集中式工作流程。我所知道的当前DVCS(git / bzr / hg)都不支持这一点。不过,那将是一个很好的特色。