經過近兩年使用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