DVCS y pérdida de datos?

Después de casi dos años de usar DVCS, parece que un "defecto" inherente es la pérdida accidental de datos: he perdido el código que no se ha enviado, y conozco a otras personas que también lo han hecho.

Puedo ver algunas razones para esto: la duplicación de datos fuera del sitio (es decir, "los commits tienen que ir a un host remoto") no está incorporada, el repository vive en el mismo directory que el código y la noción de "hackear" hasta que tengas algo que liberar "es frecuente … Pero eso no viene al caso.

Tengo curiosidad por saber: ¿has experimentado la pérdida de datos relacionada con DVCS? ¿O ha estado usando DVCS sin problemas? Y, relacionado, aparte de "recordar presionar con frecuencia", ¿hay algo que se pueda hacer para minimizar el riesgo?

Perdí más datos al eliminar los cambios no comprometidos en un VCS centralizado, y luego decidí que realmente los quería, que con cualquier cosa que haya hecho con un DVCS. Parte de eso es que he estado usando CVS durante casi una década y git por less de un año, así que he tenido muchas más oportunidades de meterme en problemas con el model centralizado, pero las diferencias en las properties del flujo de trabajo entre el dos models también son factores importantes que contribuyen.

Curiosamente, la mayoría de las razones para esto se networkingucen a "PORQUE es más fácil descartar datos, es más probable que lo conserve hasta que esté seguro de que no lo quiero". (La única diferencia entre descartar datos y perderlos es que quisiste descartarlos). El mayor factor que contribuye es probablemente una peculiaridad de mis hábitos de flujo de trabajo: mi "copy de trabajo" cuando estoy usando un DVCS suele ser varias copys diferentes. en múltiples computadoras, por lo que es less probable que la corrupción o la pérdida en un repository único o incluso la pérdida de datos catastróficos en la computadora en la que he estado trabajando destruyan la única copy de los datos. (Ser capaz de hacer esto es una gran victoria del model distribuido sobre los centralizados: cuando cada compromiso se convierte en una parte permanente del repository, la barrera psicológica para copyr los cambios tentativos es mucho mayor).

En cuanto a minimizar los riesgos, es posible desarrollar hábitos que los minimicen, pero hay que desarrollar esos hábitos. Dos principios generales allí:

  • Los datos no existen hasta que haya múltiples copys de este en diferentes lugares. Hay hábitos de flujo de trabajo que le darán múltiples copys gratis; por ejemplo, si trabaja en dos lugares diferentes, tendrá una razón para ingresar a una location común al final de cada session de trabajo, incluso si no está listo a publicar.
  • No trates de hacer nada inteligente, estúpido o más allá de tu zona de confort con la única reference a un compromiso que quizás quieras mantener. Cree una label temporal a la que pueda volver, o cree una twig temporal para realizar las operaciones. (El reflog de git te permite recuperar references antiguas después del hecho; no me sorprendería que otros DVCS tuvieran una funcionalidad similar. Por lo tanto, el labeldo manual puede no ser necesario, pero a menudo es más conveniente).

He perdido datos de un DVCS, tanto por eliminar el tree junto con el repository (sin recordar que tenía información importante), como por los errores en el uso de la command-line de DVCS (git, en el caso específico): alguna operación que fue la intención de revertir un cambio que hice realmente borró una cantidad de revisiones ya comprometidas del repository.

Existe una tensión inherente entre la distribución y la garantía de que todo está "guardado" (con la suposition subyacente de que save significa estar respaldado en otro lugar).

OMI, esto es solo un problema real si trabajas en varias computadoras al mismo time en la misma línea de trabajo (o más exactamente varios repositorys: a menudo necesito compartir los cambios entre varias máquinas virtuales en la misma computadora, por ejemplo). En este caso, sería ideal un flujo de trabajo "centralizado": se configuraría un server temporal, y en algunas twigs dadas, se usaría un flujo de trabajo centralizado. Ninguno de los DVCS actuales que conozco (git / bzr / hg) lo soportan bien. Sin embargo, sería una buena característica.