¿Procedimiento correcto (mejores prácticas?) Para mantenerse sincronizado con un repositorio remoto de Mercurial.

Question

Como antiguo usuario de Subversion, decidimos pasar a Mercurial para SCM y nos confunde un poco. Aunque Mercurial es una herramienta SCM distribuida, estamos utilizando un repositorio remoto para mantener los cambios que hacemos respaldados en un servidor, pero estamos encontrando algunos problemas iniciales.

Por ejemplo, cuando dos o tres de nosotros trabajamos en nuestros repositorios locales, nos comprometemos y luego presionamos al repositorio remoto, encontramos que se crean muchas cabezas (?). Esto nos confundió muchísimo y tuvimos que fusionarnos, etc. para solucionarlo.

¿Cuál es la mejor manera de evitar tantas cabezas y mantener un repositorio remoto sincronizado con un número de desarrolladores?

Hoy, he estado trabajando de esta manera:

1. cambiar un archivo.
2. Tire desde el repositorio remoto.
3. Actualizar copia de trabajo local.
4. ¿Merge? (¿por qué?)
5. Confirme mis cambios en el repositorio local.
6. Empuje hacia el repositorio remoto.

¿Es este el mejor procedimiento?

Aunque esto ha funcionado bien hoy, ¡no puedo evitar sentir que lo estoy haciendo mal! Para ser sincero, no entiendo por qué la fusión incluso debe hacerse en la etapa de extracción porque otras personas trabajan en archivos diferentes.

Aparte de decirme que RTFM tiene algún consejo para usar Mercurial es de esa manera? ¿Algún buen recurso en línea para obtener información sobre por qué tenemos tantas cabezas?

NOTA: He leído el manual pero realmente no da muchos detalles y no creo que quiera comenzar otro libro por el momento.

Answer 1

Definitivamente debe encontrar algunos recursos de aprendizaje.

puedo recomendar lo siguiente:

• hginit.com
• Tekpub: Mercurial

cuanto a su pregunta concreta, "¿Es este el mejor procedimiento", entonces yo tendría que decir que no.

Aquí hay algunos consejos.

En primer lugar, no necesita estar "sincronizado" con el repositorio central en todo momento. En su lugar, siga estas pautas:

• Empuje desde su repositorio local al central cuando esté satisfecho con los cambios que ha cometido. Recuerde, puede tratarse de varios conjuntos de cambios
• Tire si necesita cambios que otros hayan hecho de inmediato, es decir. hay una corrección de errores que un colega suyo ha corregido, que necesita, para continuar con su propio trabajo.
• Tire antes de empuje
• combinar cualquier cabezas adicionales que tira hacia abajo con sus propios cambios, antes de empujar, o seguir trabajando

En otras palabras, aquí hay un día típico.

Realiza los últimos cambios cuando llega por la mañana, de modo que tiene un clon local actualizado. Puede que no siempre hagas esto, si estás en medio de cambios más grandes que no terminaste ayer.

Luego empiezas a trabajar.Se comprometen pequeños conjuntos de cambios con cambios aislados. Esto no quiere decir que divida una corrección de errores más grande en muchas confirmaciones más pequeñas simplemente porque usted modifique varios archivos, pero trate de evitar la corrección de más de un error a la vez, o la implementación de más de una característica a la vez Intenta mantenerte concentrado.

Luego, cuando esté satisfecho con todos los conjuntos de cambios que ha agregado localmente, decide ingresar al servidor. Cuando intentas hacer esto, obtienes un mensaje de aborto que dice que se enviarán cabezas extra al servidor, y esto no está permitido, por lo que se cancela la inserción.

En lugar de tirar. Esto siempre se puede hacer, pero por supuesto ahora agregará cabezas adicionales en su clon local, en lugar de en el servidor.

Luego fusiona, la cabeza adicional que obtuvo del servidor, con su propia cabeza, la que creó durante el día mediante la asignación de nuevos conjuntos de cambios a su clon. Usted resuelve cualquier conflicto de fusión.

Luego presionas, y ahora debería tener éxito. En el caso de que alguien haya logrado enviar más conjuntos de cambios al depósito central mientras estuvo ocupado fusionándose, obtendrá otro aborto y tendrá que enjuagar y repetir.

El historial ahora mostrará múltiples ramas paralelas de desarrollo, pero siempre debe permanecer en un máximo de 1 cabeza en su repositorio central. Si, más adelante, comienzas a utilizar ramas con nombre, puedes tener 1 cabeza por rama con nombre, pero trata de evitar esto hasta que obtengas la rama predeterminada.

¿En cuanto a por qué necesita fusionarse? Bueno, Mercurial siempre trabaja con revisiones que son instantáneas de todo el proyecto, lo que significa que dos ramas, aunque contienen cambios en diferentes archivos, en realidad se consideran dos versiones diferentes de todo el proyecto, y debes decirle a Mercurial que debería combinar ellos para volver a una versión.

Answer 2

Por un lado, puede tirar en cualquier momento; tirar solo agrega conjuntos de cambios a su repositorio, pero no cambia los archivos de trabajo locales (excepto si ha activado la actualización posterior).

La fusión es necesaria si alguien más ha realizado cambios en la misma rama en la que está trabajando actualmente. Esto creó una rama implícita, y la fusión simplemente los vuelve a unir. Puede ver esto muy bien con la "vía del ferrocarril" en la vista del repositorio. Básicamente, siempre que no se fusione, permanezca en su propia pista "privada", y cuando desee agregar los cambios (puede ser cualquier cantidad de conjuntos de cambios) la fusionará de nuevo en la rama de destino (por lo general, "predeterminada")) Es fácil: ¡nada como fusionarse en versiones antiguas de SVN!

Por lo tanto, el flujo de trabajo no es tan rígido como lo mostraba; que es de la misma familia:

• tirar tanto como desee
• hacer cambios y comprometerse localmente como la frecuencia que desee
• Cuando los cambios deben integrarse, fusionarse con la rama de destino (puede ser un menor revisión que la más nueva), confirmar y presionar

Este flujo de trabajo se puede ajustar de alguna manera, por ejemplo mediante el uso de ramas con nombre y, a veces mediante el uso de rebase. Sin embargo, usted y su equipo deben decidir sobre el flujo de trabajo que se utilizará; Mercurial es bastante flexible en este sentido.

Answer 3

http://hginit.com tiene un buen tutorial.

En particular, encontrará la lista de pasos que tenemos aquí: http://hginit.com/02.html (en la parte inferior de la página)

La diferencia entre esos pasos y la suya es que usted debe comprometerse después del paso 1. De hecho por lo general, se comprometerá varias veces en su repositorio local antes de pasar al paso pull/merge/push. No necesita compartir cada compromiso con el resto de desarrolladores de inmediato. A menudo tendrá sentido hacer varios cambios relacionados y luego impulsar todo eso.