¿Los sistemas de control de versiones distribuidas promueven malos hábitos de copia de seguridad?

Question

En un DVCS, cada desarrollador tiene un repositorio completo en su estación de trabajo, al que pueden enviar todos sus cambios. Luego pueden fusionar su repositorio con el de otra persona, o clonarlo, o lo que sea (como yo lo entiendo, no soy un usuario de DVCS).

Para mí, que marca un efecto secundario, de ser más vulnerable a olvidarse de hacer una copia de seguridad. En un sistema centralizado tradicional, tanto usted como desarrollador y las personas a cargo saben que si compromete algo, se mantiene en un servidor central que puede tener soluciones de respaldo adecuadas.

Pero el uso de un DVCS, parece que sólo tiene que empujar a su trabajo a un servidor cuando sientes que compartirlo. Está muy bien que tengas el repositorio localmente para que puedas trabajar en tu sucursal de funciones durante un mes sin molestar a nadie, pero significa (creo) que no es suficiente registrar tu código en el repositorio, debes recordar hacer regularmente empuja a un servidor respaldado.

También significa, ¿no es así, que un jefe de equipo puede no ver todos aquellos agradable SVN correos electrónicos de mantener una idea aproximada de lo que está pasando en el código base?

¿Alguno de esto es un problema real?

Answer 1

que pueda Comprenda su preocupación acerca de los desarrolladores que olvidan las copias de seguridad una vez que su diferencia local se ha ido (porque se han comprometido localmente) y deja de molestarlos con una gran cantidad de copias de seguridad. ¡Creo que la solución puede estar en mejores herramientas, herramientas moar! Puede configurar un trabajo cron en cada casilla de desarrollo que empuje hasta el último objeto accesible en su repositorio al repositorio central, y los etiquete en el repositorio central (respaldado) con ramas espaciadas por nombre. Creo que "git push" puede hacer esto, dado el refspec correcto. Entonces, todo lo que no está haciendo está afectando el estado de sus ramas públicas.

¿Pero realmente necesita un proceso de copia de seguridad tan agresivo como antes, cuando el repositorio existía solo en un solo lugar? Con un DVCS, necesita una categoría de catástrofes mucho más alta para perder todo su código. Ahora necesita un asteroide o una bomba que llegue a su oficina (y a todos los miembros de su equipo fuera del sitio), en lugar de un disco duro o una controladora RAID que salgan mal. Tenga en cuenta que no defiendo el descuido; Estoy abogando por la igualdad de riesgos a un costo menor.

Answer 2

Tener una copia local del repositorio podría alentar los malos hábitos de copia de seguridad, en caso de que hubiera una holgura. Sin embargo, su repositorio principal DEBE tener una copia de seguridad.

La "copia local de todo el repositorio" tiene un uso mucho más importante que una copia de seguridad. Reduce la latencia de examinar el historial de la base de código, por ejemplo, difiriendo de la última versión, de ser un viaje redondo de red a un viaje a su disco duro local.

Eso no suena tan grande si su repositorio principal está en su LAN gigabit. Si eres un teletrabajador, y el repositorio está a 600+ ms de una VPN, hace una gran diferencia.

nunca he mirado en él, pero estoy seguro de que ambos Mercurial Git y apoyo post-commit ganchos, lo que le permite configurar los correos con que van a la líder del equipo. Entonces cada desarrollador podría configurar su repositorio en consecuencia, o tener un repositorio provisional que permita funciones a medio hacer con los correos de confirmación, o lo que sea.

Editar: En cuanto al comentario de John acerca de la pérdida de un experimento de larga duración porque no estaba listo para comprometerse con el repositorio principal: trabaje en una rama separada y periódicamente envíe sus cambios al maestro. Todavía obtienes todos los beneficios de trabajar contra un repositorio local (principalmente, para mí, muy baja latencia), y aún así no molestar a tus colegas con tu característica a medio hacer ... y aún puedes almacenar tus cambios en tu máquina, en un lugar donde su administrador puede respaldar correctamente el repositorio.

Answer 3

No creo que tengas un automatismo en esto. VCS distribuido o centralizado se puede combinar con copia de seguridad (o no). Todo es una cuestión de disciplina en el equipo.

Lo mismo para commit-emails. Si el equipo tiene la disciplina para impulsar cambios regularmente en los repositorios correctos, también puede tener una lista de correo comprometida.

Los malos hábitos también pueden crecer en un equipo con VCS centralizado. Siempre tienes que luchar contra los malos hábitos.

Answer 4

En la mayoría de los lugares en los que se imaginan que es probable que haya todavía un repositorio central desde donde se hacen construye y poner a prueba. Si quiere su código en la compilación, debe ser empujado centralmente.

Esto también es un problema de gestión, dígale a su equipo, empuje periódicamente (al menos diariamente) para que se haga una copia de seguridad de su código. Si no se está haciendo, saca el gran palo.

También me gustaría señalar, que si usted está confiando en mirar las confirmaciones para ver lo que sus empleados están haciendo, es probable que tenga algunos temas de mayor tamaño que lo podría hacer en frente ...