¿Es verdad en Mercurial (hg), lo mismo que Git, que una revisión que usted haya comprometido solo puede tener código no modificado por usted? (una fusión)

Parece que en SVN, cuando realizas una fusión, no hay una revisión registrada por ti. Todos sus "commits" solo deben tener un código que usted modifique.

Pero en Mercurial, ese no es el caso. Sus compromisos de "fusión" son cometidos por usted, pero generalmente contienen cambios realizados por otras personas. Y si esa confirmación desencadena un error en la testing automatizada, entonces ¿puede ser la "fusión" la que rompió la base del código, lo que significa que los otros cambios no funcionaron con los tuyos o viceversa? (pero los otros cambios pueden no haber revelado el error porque (1) puede que no haya llegado tan lejos en la testing. (2) la testing se agrupa por lotes, y si la testing 102 tardó 1 hora en ejecutarse y hay 3 impulsos dentro de esa hora, solo se testing la última versión empujada)

¿Es este el comportamiento igual que Git también?

Entonces, realmente tienes que mirar la testing para ver qué es lo que la causa y arreglarla … pero ¿quién debería verla, tú o el miembro de tu equipo?

El encuentro inicial de este comportamiento se siente un poco extraño …

La fusión será cometida por quienquiera que lo haga. Pero puedes bisectar el tree y luego culpar a la persona que causó el problema. Además, si tiene alguna idea de un par de personas que son responsables, debe decirles que la miren. Si escribiste bien tus testings, deberían darte una idea de dónde está el problema. Si sus características no pueden resolverse para que funcionen, entonces tendrá que ser diplomático y tomar algunas decisiones.

No entiendo muy bien por qué preguntas. Cuando se une a dos líneas de desarrollo (realizando una combinación), creará una combinación de fusión , es decir, una revisión que representa este acto de unir dos líneas de la historia. En Git y Mercurial, tal compromiso restring a ambos padres; en Subversion dicha revisión restring ambas revisiones para todos los files (si lo entiendo correctamente).

En la mayoría de los casos, la confirmación de fusión se crearía automáticamente ; en Git (y creo que también en Mercurial) usando fusión de 3 vías, donde el 3er punto (además de las puntas de ambas líneas fusionadas de desarrollo / twigs) es antecesor común. Subversion solo recientemente (desde la versión 1.5, si no recuerdo mal) almacena la información requerida para calcular la base de combinación (sin usar herramientas de terceros como SVK o svnmerge). Tenga en count que, por lo que yo entiendo, Subversion fusiona files, mientras que tanto Git como Mercurial fusionan las revisiones como un todo.

A veces, la fusión automatizada falla, y usted tiene que resolver los conflictos de forma manual , y luego confirmar la finalización de una fusión. Esto es algo que podría suceder en cualquier sistema de control de versiones.

Independientemente de si la fusión automatizada tuvo éxito o no, el acto de fusionarse (el compromiso de fusión en Git y Mercurial) podría introducir errores. Tomemos como ejemplo una situación en la que un lado cambia de convención de llamadas para alguna function, y el otro lado agrega otro sitio de llamada con API anterior. La combinación automática puede tener éxito, pero la combinación generará un error, aunque ambas líneas de desarrollo están libres de errores.

Sin embargo, git bisect puede encontrar que fue un commit de fusión (acto de fusión) que introdujo el error.