Gráfico de historia de Git comparado con el gráfico de historia de SVN

Estoy tratando de entender la diferencia entre un gráfico de Git y SVN. Sé que el gráfico de Git es un DAG

Pero al comparar estos dos:

Gráfico de historial de ejemplo de Git: http://gugod.org/2009/12/12/3389620_29acb2fe86d3e03e7f8c665c4225c454.jpg

Ejemplo de gráfico de historial de SVN: http://svn-graph-branches.googlecode.com/svn/wiki/nxt-python-r222.svg

Realmente no sé cómo aplicar ese conocimiento, parece bastante similar a mí.

Aquí:

http://ericsink.com/vcbe/html/directed_acyclic_graphs.html

Dice que: las herramientas de segunda generación tienden a modelar la historia de un repository como una línea

Pero eso no encaja realmente con el ejemplo SVN anterior del gráfico de historial, por lo que SVN no es una herramienta de segunda generación o el artículo es incorrecto. ¿Alguien podría ayudar a aclarar lo anterior?

La diferencia es que en SVN, todos siempre tienen la misma secuencia de compromisos. En SVN, una copy de trabajo completamente actualizada es algo definido, y siempre tiene exactamente el mismo order de nodos.

En Git, un repository puede estar completamente "actualizado" con respecto a otro repository, pero un tercer repository podría tener un set de nodos completamente diferente después de un cierto punto de historia compartida.

En otras palabras, si creo la versión 5 en SVN, y la confirmación inmediatamente anterior en order cronológico es la versión 4, eventualmente todos en el proyecto tendrán que ver esa misma versión 5. Sé que la versión 3 vino antes de la versión 4 y que nadie podría tener una versión 5 'que necesitaré fusionar. El pedido siempre será, en cada copy de trabajo en todas partes, 3-4-5-5 '.

Pero en herramientas distribuidas como Git o Mercurial, si creo la versión 397afeg815, y la versión inmediatamente anterior es cronológicamente 8290e7ab8f, eso no me dice nada sobre dónde podría caer la versión 839eabcdef7, y algún tipo en China podría haber cometido la versión 9876543231abc eso también viene exactamente después de 8290e7ab8f. Las twigs de los treees aquí, no son lineales; no hay un order definido más allá de las relaciones entre padres e hijos. A diferencia de SVN, donde cada commit tiene exactamente un padre, y como máximo un hijo (en la misma sucursal), en Git o Mercurial un commit puede tener múltiples padres y varios hijos en la misma sucursal.

Cuando SVN se bifurca, es una elección deliberada, y todos verán la sucursal en el mismo punto, y no hay dudas sobre qué línea de desarrollo es el tronco en el futuro. Git y Mercurial y otros sistemas similares crean potencialmente una nueva sucursal con cada compromiso, y si una determinada comisión está en "troncal" depende completamente del process de desarrollo de un equipo o incluso de a quién se lo pides.

Editar para mayor aclaración

La diferencia entre un verdadero DAG como Git o Mercurial, y una historia "lineal" como SVN es que puedes reorderar los nodos en el DAG de Git como mejor te parezca. Aún tendrás la misma historia. De hecho, dependiendo del order en el que hagas / envíes / envíes cosas, en realidad puedes ver varias permutaciones diferentes del DAG en tus repositorys. El order de los nodos no importa, solo la relación padre-hijo.

La historia de SVN es diferente. Solo hay UNA forma de ver un tree SVN. La versión 2 siempre sigue a la versión 1. La versión 3 siempre sigue a la versión 2. No hay duda en qué order sucedieron las cosas para una historia "lineal". El order de los nodos es inmutable. En el caso de SVN, incluso cruza los límites de las sucursales.

    Intereting Posts