经过近两年使用DVCS,似乎一个固有的“缺陷”是意外的数据丢失:我丢失了没有被推送的代码,并且我知道其他人也一样。DVCS和数据丢失?
我可以看到一些原因:异地数据重复(即“提交必须去远程主机”)没有内置,存储库与代码和概念位于同一目录中“黑客”,直到你有东西要发布“是流行的......但那不是重点。
我很想知道:您是否遇到过DVCS相关的数据丢失?或者你没有麻烦地使用DVCS?而且,除了“记得经常推动”之外,还有什么可以做到最大限度地降低风险?
经过近两年使用DVCS,似乎一个固有的“缺陷”是意外的数据丢失:我丢失了没有被推送的代码,并且我知道其他人也一样。DVCS和数据丢失?
我可以看到一些原因:异地数据重复(即“提交必须去远程主机”)没有内置,存储库与代码和概念位于同一目录中“黑客”,直到你有东西要发布“是流行的......但那不是重点。
我很想知道:您是否遇到过DVCS相关的数据丢失?或者你没有麻烦地使用DVCS?而且,除了“记得经常推动”之外,还有什么可以做到最大限度地降低风险?
我已经从一个集中化的VCS中对未提交的变化进行破坏,然后决定我实际需要它们,而不是从我用DVCS完成的任何事情中丢失了更多的数据。其中一部分是我已经使用了CVS近十年,并且在一年之内使用了git,所以我有更多的机会来解决集中式模型的问题,但是在工作流的属性两种模式也是主要的促成因素。有趣的是,其中大部分原因归结为“因为丢弃数据更容易,所以我更可能保留它直到我确定我不需要它”。 (丢弃数据和丢失数据之间的唯一区别就是你想放弃它。)最大的影响因素可能是我工作流习惯的一个怪癖 - 当我使用DVCS时,我的“工作副本”通常是几个不同的副本传播在多台计算机上运行,所以在我一直致力于处理的计算机上,单个回购或甚至是灾难性数据丢失的损坏或损失不太可能破坏数据的唯一副本。 (能够做到这一点是分布式模型比集中式模型的一大胜利 - 当每一次提交变成存储库的永久部分时,复制临时变化的心理障碍要高得多。)
只要最大限度地减少风险,有可能发展习惯,尽量减少他们,但你必须发展这些习惯。两个一般原则有:
我已经从DVCS丢失了数据,这既是因为删除了树以及存储库(不记得它有重要信息),也因为使用DVCS命令行(在特定情况下为git)时出错:一些旨在恢复我所做的更改的操作实际上已从存储库中删除了一些已提交的修订。
在分配和确保一切都“保存”之间存在一种固有的紧张关系(假设保存意味着在其他地方备份)。
IMO,这只是一个真正的问题,如果你在同一个工作线上同时在几台计算机上工作(或者更确切地说是几个存储库:我经常需要在同一台计算机上的多个虚拟机之间共享更改)。在这种情况下,“集中式”工作流将是理想的:您将设置一个临时服务器,并在某些给定的分支上使用集中式工作流程。我所知道的当前DVCS(git/bzr/hg)都不支持这一点。不过,这将是一个很好的功能。
Bazaar在“branch”和“checkout”之间有区别,后者是绑定到另一个目录中的存储库的工作副本。在这样的树上,每个提交都是隐式推送(就像集中式VCS一样)。这可以让你避免招贴画的问题多少,这是另一回事,但你可以获得你正在谈论的中央工作流程。 – quark 2009-07-25 06:18:57