DVCS y pérdida de datos?

Question

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.

Veo 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 repositorio vive en el mismo directorio que el código y la noción de "piratear" hasta que tengas algo que liberar "es frecuente ... Pero eso no viene al caso.

Tengo curiosidad por saber: ¿ha 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?

Answer 1

Perdí más datos de los cambios no confirmados en un VCS centralizado, y luego decidí que realmente los quería, que de 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 menos de un año, así que he tenido muchas más oportunidades de meterme en problemas con el modelo centralizado, pero las diferencias en las propiedades del flujo de trabajo entre el dos modelos también son factores importantes que contribuyen.

Curiosamente, la mayoría de las razones para esto se reducen 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 "copia de trabajo" cuando estoy usando un DVCS suele ser varias copias diferentes. en múltiples computadoras, por lo que es menos probable que la corrupción o la pérdida en un repositorio único o incluso la pérdida de datos catastróficos en la computadora en la que he estado trabajando destruyan la única copia de los datos. (Ser capaz de hacer esto es una gran victoria del modelo distribuido sobre los centralizados: cuando cada commit se convierte en una parte permanente del repositorio, la barrera psicológica para copiar los cambios tentativos es mucho más alta).

En cuanto a minimizando los riesgos, es posible desarrollar hábitos que los minimicen, pero debes desarrollar esos hábitos. Dos principios generales ahí:

• de datos no existe hasta que no múltiples copias del mismo en diferentes lugares . Hay hábitos de flujo de trabajo que le darán múltiples copias gratis - por ejemplo, si trabaja en dos lugares diferentes, tendrá una razón para presionar a una ubicación común al final de cada sesión de trabajo, incluso si no está listo para publicar.
• No intente hacer nada inteligente, estúpido, o más allá de su zona de confort con la única referencia a una confirmación que quizás quiera conservar. Cree una etiqueta temporal a la que pueda recurrir, o cree una bifurcación temporal para hacer las operaciones en . (Reflog de Git permite a recuperar viejas referencias después del hecho ; yo estaría sorprendido si otros DVCSs tienen una funcionalidad similar etiquetado Así manual puede no ser necesaria , pero es a menudo más conveniente de todos modos..)

Answer 2

He perdido datos de un DVCS, tanto por eliminar el árbol junto con el repositorio (sin recordar que tenía información importante), como por los errores en el uso de la línea de comando DVCS (git, en el caso específico): alguna operación que estaba destinada a revertir un cambio que realicé en realidad borró una cantidad de revisiones ya comprometidas del repositorio.

Answer 3

Existe una tensión inherente entre la distribución y la garantía de que todo está "guardado" (con la suposición subyacente de que los medios guardados están respaldados en otro lugar).

IMO, esto es solo un problema real si trabaja en varias computadoras al mismo tiempo en la misma línea de trabajo (o más exactamente varios repositorios: a menudo necesito compartir cambios entre varias VM en la misma computadora, por ejemplo) En este caso, sería ideal un flujo de trabajo "centralizado": se configuraría un servidor temporal, y en algunas ramas 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.