svn - tortoise - que son branches

Mercurial en comparación con las sucursales privadas en SVN (2)

Otro problema que debe tenerse en cuenta es que los desarrolladores se sentirían reacios a presentar un código a medias en subversión, incluso si se trata de una sucursal privada, ya que su incompletitud sería visible para sus compañeros. La presión de grupo para enviar un código de trabajo excelente es muy alta en un sistema de control de versiones centralizado. Esto conduce a compromisos poco frecuentes que combinan problemas de fusión más grandes.

En un DVCS, los desarrolladores pueden hacer cualquier cosa con su código y aun así hacer un envío ya que nadie más conocerá los cambios hasta que se hagan los cambios. Tienen el privilegio de experimentar incrementando así la productividad y la eficiencia del código porque todo lo que hacen se puede revertir.

Supongamos por un minuto que el soporte de rama / fusión en SVN es tan bueno como en Mercurial.

Considere por un lado un sistema SVN donde las personas siempre trabajan en sus propias ramas privadas, y luego, cuando se encuentren en un punto adecuado, fusionen su rama privada en la rama "principal" (o lo que sea que sucursal "parental" sea). Periódicamente pueden fusionarse de otra manera para actualizar su sucursal privada.

Luego, por otro lado, considere la configuración de Mercurial de tener un repositorio central y cada persona tirando y empujando hacia / desde su propio repositorio al cual se comprometen cuando lo deseen.

Entonces, la rama privada en SVN corresponde al repositorio local en Mercurial y la extracción / inserción en HG corresponde a la fusión ay desde la rama privada en SVN.

¿Esto no permite que SVN esencialmente refleje la configuración de Mercurial en este caso? ¿Qué otras ventajas tiene Mercurial en el escenario?

Tenga en cuenta que mi frase de apertura - "asumir por un momento" - al menos en la versión de SVN que tenemos, es donde el modelo SVN se nos viene abajo. La cantidad de fusión que implicaría, y particularmente la fusión hacia adelante y hacia atrás entre la rama principal y la privada, sería un conflicto. Si SVN fuera tan bueno en rastrear sucursales y se fusionara como Mercurial, ¿resolvería eso el problema en SVN? ¿Es el último código de servidor SVN que admite el seguimiento de ramales de seguimiento hasta ese tipo de uso?

Gracias.

No, Subversion todavía no puede fusionarse tan sólidamente como Mercurial. Doy un ejemplo explícito de cómo Subversion no puede fusionar dos ramas en esta respuesta . No hay nada que impida que un sistema centralizado sea bueno para fusionarse, es solo que las ramas se usan tanto en un sistema descentralizado que se lo obliga a ser bueno para fusionarse.

Además del soporte de fusión, la mayor ventaja de Mercurial sobre Subversion es la flexibilidad del control de versión descentralizado:

Puedes hacer muchos pequeños commits y luego hacer hg rebase --collapse para combinarlos en un commit más grande y mejor antes de empujarlos al mundo.
Puede usar la extensión MQ o la extensión rebase para refinar los conjuntos de cambios antes de publicarlos.
Puede comprometerse de forma segura, y luego cambiar de opinión y deshacerse de las cosas con la hg strip o la hg clone -r más segura hg clone -r .

Esto le permite experimentar más libremente y el resultado final es que Mercurial se convierte en una red de seguridad de apoyo en lugar de un obstáculo. Es profundamente irónico que herramientas como Subversion terminen siendo algo que las personas no usan, no se comprometen con sus cambios durante días porque temen romper la compilación, y no usan ramas porque han sido quemadas por ellos. en el pasado.

Lo anterior era solo flexibilidad local: Mercurial también le permite orquestar flujos agradables de conjuntos de cambios entre repositorios: puede tener un repositorio donde un guardián de puerta hace control de calidad y solo permite el cambio de conjuntos después de probarlos. Ese tipo de flexibilidad está integrada en el modelo descentralizado.