Evitar que el código inestable entrar en línea por defecto

Question

Actualmente, tengo 2 repositorio. Un repositorio es nombrado jstock, que contiene todo el código fuente estable.

Otro repositorio llamado jstock-refactor-calendar-to-joda, que se clonó a partir de jstock, y contiene todo el código característica experimental inestable.

Todo el cambio-set en rectángulo rojo es inestable código de característica experimental. Ellos no han terminado todavía. Por lo tanto, no tengo intención de hacer que se funden con el cambio-set en rectángulo verde (rectángulo verde indica que esos son cambios en el conjunto estable)

Después de tirones jstock-refactor-calendar-to-joda de jstock, aquí es cómo se ve.

Ahora, me gustaría dejar que el código experimental visible para jstock (pero no entrar en línea por defecto, ya que son inestables)

Por lo tanto, cuando realizo empujón de jstock-refactor-calendar-to-joda a jstock, aquí es lo que me pasa.

Ahora todo el código inestables son pertenece a la línea por defecto!

Esto no es lo que quieren. En jstock, deseo que el código estable (en el rectángulo verde) permanece en default (lado izquierdo), el código inestable (en el rectángulo rojo) permanece en el lado derecho. Tenga en cuenta que, yo no quiero que se va a combinar todavía, pero me gustaría tener dos líneas de desarrollo (estables e inestables) siendo visible.

¿Hay algún paso que tenía mal hecho?

Answer 1

En este caso se debe tener "fuerza" empujó a medida que haya creado múltiples cabezas. Tanto estas cabezas son en la rama "por defecto". No hay problema con esto como tal, pero el problema que preocuparse es que su nuevo jefe (con el código inestable) es la "punta" de la rama por defecto.

Desde el Mercurial FAQ :

La punta es siempre una cabeza. Si hay múltiples cabezas en un repositorio, sólo se uno de ellos es la punta. Dentro de un repositorio, changesets se numeran secuencialmente, de modo que la punta tiene la más alto número de secuencia. La palabra funciones de "punta" como una etiqueta especial para denotar el conjunto de cambios punta, y puede ser utilizado en cualquier lugar de un ID de cambios o etiqueta es válido.

Hubiera sido mejor haber empujado a estos cambios en una rama llamada, Lasse sugiere , pero está donde está. En este caso, usted (o alguien tirando de este repositorio por primera vez) es necesario actualizar la copia de trabajo para estar en la parte estable de su rama por defecto.

hg update -r 12345

(donde 12345 es el número de revisión "En lugar de limitar la moneda ..."

Para los desarrolladores que ya tienen este repositorio, cuando se ponen sus cambios inestables verán las múltiples cabezas pero su copia de trabajo no se actualizarán automáticamente a su nueva sucursal.

Answer 2

Esto también fue publicada en la lista de correo Mercurial y abajo es mi respuesta :

La ubicación de las dos ramas (anónimo) en el visor de registro no es importante: No existe lado izquierdo o derecho, el orden sólo depende del orden en que se haya realizado los los tirones y empujones

.

Lo que necesita es una manera de etiqueta los conjuntos de cambios desde el establo y las ramas inestables, para que pueda hacer un seguimiento de cuál es cuál. Hay tres formas principales para hacer esto:

• clones independientes:. Esta es la forma trivial en el que ya ha utilizado dónde guarda un clon separado para las diferentes ramas

  Tiene la ventaja de que se puede tirar a la basura los conjuntos de cambios fácilmente con sólo borrar el clon.

  Tiene el inconveniente de que en realidad no obtener una visión completa de lo que está sucediendo ya, permanezcan aislados los conjuntos de cambios.

• ramas con nombre: Ver mi guía aquí si no lo ha hecho:

  http://mercurial.aragost.com/kick-start/en/tasks /

  La ventaja de ramas nombradas es que ponen una etiqueta en cada conjunto de cambios para que pueda realizar un seguimiento de dónde vienen. Si usted tiene una rama llamada llamada 'refactor de agenda a-joda', entonces puede hacerlo

  hg update refactor-calendar-to-joda
  

  con el fin de actualizar la copia de trabajo a la punta de esa rama. Cuando las nuevas confirmaciones se realizan en la rama, la punta de la rama mueve a lo largo, y así se puede pensar en 'refactor de agenda a-joda' como una etiqueta flotante.

  Para volver a la rama por defecto, ejecutar

   hg update default
  

  Aquí es donde el desarrollo normal debe tener lugar.

  ramas nombradas son buenas para las ramas que son estables en el tiempo más largo o donde el nombre también hace sentido años más tarde. Por ejemplo, si utiliza un gestor de fallos, entonces le sugiero la creación de un error de seguimiento de la refactorización y luego llamar a la rama 'bug XX'. Así la gente puede buscar el número de error justo en el futuro.

• marcadores: Marcadores dan nombres a los conjuntos de cambios y como con ramas nombradas, puede actualizar a un marcador:

  hg update refactor-calendar-to-joda
  

  Sin embargo, a diferencia de ramas nombradas, los marcadores viven fuera de la gráfica de cambios. Porque no son parte de los propios conjuntos de cambios, los marcadores se pueden mover, borrar, renombrar, etc Usted puede empujar y tirar marcadores entre repositorios.

Así que utilizar ramas nombradas para los nombres persistentes a largo plazo, marcadores de uso de ramas de corta duración, y utilizar repositorios separados si te gusta tener cosas separadas.

Por último, ver esta guía para más información sobre este tema:

http://stevelosh.com/blog / 2009/08 / a-guía-a-ramificación-en-mercurial /

Answer 3

Lo que has hecho es perfectamente bien. Tiene dos cabezas en la misma rama 'default' llamado. Esta es una manera completamente normal al trabajo. He aquí una descripción bastante decente de lo que está pasando:

http: // stevelosh .com / blog / 2009/08 / a-guía-a-ramificación-en-mercurial / # ramificación-anónima

Como Nick sugiere, las personas que ya tienen un clon tendrá la nueva cabeza cuando se ponen y las personas que recién clon se obtiene tanto -. Y eso es muy bien

Cuando la gente hg update default o simplemente hg update se trasladaron a la más reciente conjunto de cambios en la rama default, por lo que acaba de hacer una más comprometerse con el "lugar de limitar cifras decimales moneda ..." cambios como su matriz de esta manera:

hg update REVSION
...edit
hg commit

Y van a ser actualizados automáticamente a la rama anónima que quiere cuando se clonan / actualización.

Lo que hay que tener en cuenta es que mercurial existido durante mucho tiempo antes de que se había nombrado ramas, así que todo se puede hacer con ramas nombradas se pueden hacer con ramas anónimos.

Si decide tener dos cabezas no diferenciadas en ese repo es demasiado confuso considerar dar un vistazo a marcadores. Son etiquetas adhesivas que hacen un seguimiento de las puntas de las ramas Anónimo -. Más flexibles que las ramas nombradas en que no son permanentes

http: / /stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/#branching-with-bookmarks

Answer 4

En este caso probablemente debería haber esperado a empujar, y hacer que el conjunto repositorio esté disponible.

O, cuando empezó esa rama, que debería haber dado un nombre. Puede tener varias ramas no identificados todos ellos pertenecientes a la misma rama llamada.

En otras palabras, todos los conjuntos de cambios que estamos viendo no es parte de la rama default, sin embargo, la etiqueta se muestra solamente para la punta de esa rama. Dado que los nuevos conjuntos de cambios son ahora la punta, que es donde se muestra la etiqueta en la interfaz de usuario.

Si se hubiera dado un nombre, por defecto hubiera sido todavía abajo en su conjunto de cambios tipmost en la rama por defecto.

Para corregir esto, se tendría que "Replay" esos conjuntos de cambios, uno por uno. No sé la mejor manera de hacerlo, pero basta con decir que obtendrían nuevos valores hash, así que cualquiera que ha tirado esos conjuntos de cambios ya se arriesgan empujando de nuevo en el marco de la rama por defecto.