¿Cómo hacer una copia de seguridad de los repositorios Mercurial locales y usar rebase?

Question

Mi empresa se está moviendo de Subversion a Mercurial. Una de las razones es que con Hg esperamos poder trabajar de forma más independiente.

Estamos deseando utilizar el rebase como nuestra forma principal de actualizar desde el repositorio principal, al menos al principio, para mantener el historial en una línea, facilitando la transición desde Subversion.

En este momento, si tenemos que trabajar de forma independiente, tenemos dos opciones: crear una rama en Subversion, y cometer allí (también conocido como fusionar infierno), o no comprometerlo en absoluto. Con Mercurial esperamos poder seguir comprometiéndonos localmente, y volver a basarnos de vez en cuando, ganando así independencia mientras nos mantenemos libres de los costos de administración de creación de sucursales con nombre.

Todo esto suena bien hasta que la copia de seguridad entra en escena. Con Subversion era obvio que si alguien no se comprometía, su trabajo podría perderse. Pero no comprometerse se volvió incómodo rápidamente (sin historial, sin mensajes de registro, etc.), por lo que las personas se comprometerían una y otra vez sin embargo.

Con Mercurial, será posible continuar cometiendo y rebasando sin presionar durante largos períodos de tiempo, poniendo mucho más trabajo en riesgo. Entonces surge una pregunta: ¿cómo hacer una copia de seguridad de las cosas en las máquinas de los desarrolladores?

• Una solución sería utilizar algún software de copia de seguridad externo, pero eso no parece una muy buena idea.
• También podríamos presionar al repositorio principal todo el tiempo (¿quizás incluso automáticamente?), Pero esto imposibilitaría el uso de rebasado, y daría lugar a muchas cabezas colgantes en la línea principal.
• Podríamos ingresar a un repositorio de respaldo e intentar tener solo una cabeza en el repositorio principal. Esto suena muy complicado.

¿Hay alguna otra forma de hacerlo? Me gustaría encontrar una solución que permita a nuestros desarrolladores utilizar la mayor parte de sus conocimientos de Subversion al principio.

Answer 1

También podría dar a cada desarrollador de un acuerdo de recompra:

 
https://example.com/repos/awesome-product 
https://example.com/repos/awesome-product-wolever 
https://example.com/repos/awesome-product-pintér 

Donde pueden empujar a todo lo que quieran.

Significaría mucho colgando cabezas, pero eso es probablemente correcto porque nadie los miraba hasta que llega el momento de restaurar ... Entonces será simplemente pedir sólo los antepasados ​​de la punta actual:

 
hg pull https://example.com/repos/awesome-product-wolever -r tip 

Si estuviera usando este esquema, que se había propuesto:

 
[paths] 
backup = https://example.com/repos/awesome-product-wolever 

en .hgrc/hgrc.

Como alternativa, puede dar a cada uno dev repo copia de seguridad global mediante el establecimiento de este mundial en su ~/.hgrc:

 
[paths] 
backup = https://example.com/repos/wolever-backup 

Answer 2

Sólo para tirar esto por ahí: Creo que estás cometiendo un error. Una historia lineal no es un gran problema y el pull/merge es el flujo de trabajo mercurial mucho más normal. Abraza una historia no lineal y deja rebase para ocasiones especiales.

Usted dice "Con Mercurial esperamos poder seguir comprometiéndonos localmente, y rebasearnos de vez en cuando, ganando así independencia sin los costos de administración de crear ramas con nombre", pero en mercurial se usan ramas sin nombre para esto, entonces no hay costos de administración.

Consulte http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/#branching-anonymously para obtener una explicación de cómo las ramas sin nombre creadas automáticamente le darán exactamente lo que usted quiere sin problemas.

sé que suena demasiado bueno para ser verdad aceite de serpiente, pero su gente simplemente hg pull y hg merge y hg push pueden cuando están a través y sin que nadie tenga que pensar en nombres de rama, o que tiene lo clonar, o cualquier cosa, tendrás un centro coordinado con trabajo desconectado.

Answer 3

Creo que lo estás haciendo mal.
Lo que usted describe se parece más a que está tratando de poner en marcha una herramienta para asegurar/aplicar un proceso, en lugar de apoyar el proceso.

Trabajar de forma descentralizada es un cambio bastante grande en comparación con el enfoque centralizado, y al tratar de poner la restricción amable que describe, es muy probable que cause más daño que bien a la experiencia percibida por los desarrolladores.

Si tiene miedo de que no envíen sus cambios regularmente al repositorio principal, sería bueno preguntarse (y preguntar también) "¿Estamos listos para cambiar nuestro proceso? ? " Mucha gente todavía afirma que el DVCS traerá caos a su fábrica de software. Es cierto que los DVCS no imponen una forma lineal de trabajar (punto único de falla), pero lo que trae caos no es la herramienta, es el espíritu de equipo que construiste en tu empresa.

Ahora, si TIENE QUE migrar a Mercurial (porque ya está vendida a nivel de gestión, o lo que sea), pero se siente más cómodo con el enfoque SVN, con un poco de "más", trate de usar HgSubversion primero. La migración será aún más fácil más tarde.