En programación informática, el control de versiones distribuido permite a muchos desarrolladores de software trabajar en un proyecto común sin necesidad de compartir una misma red. Las revisiones son almacenadas en un sistema de control de versionesdistribuido (DVCS, por sus siglas en inglés).
Distribuido vs. Centralizado
El control de versiones distribuido toma un enfoque entre iguales (peer-to-peer), opuesto al enfoque de cliente-servidor de los sistemas centralizados. En lugar de un único repositorio central en el cual los clientes se sincronizan, la copia local del código base de cada peer es un repositorio completo.
El control de versiones distribuido sincroniza los repositorios intercambiando ajustes (conjuntos de cambios) entre iguales. Esto establece algunas diferencias importantes en comparación a un sistema centralizado:
No existe una copia de referencia del código base por defecto; solo copias de trabajo.
Operaciones comunes (como commits, visualización del historial, y revertir cambios) son rápidas, porque no existe necesidad de comunicación con un servidor central.
La comunicación con el servidor sólo es necesaria cuando se comparten cambios entre iguales (peers).
Cada copia de trabajo funciona efectivamente como una copia de seguridad remota del codebase y de su historial de cambios, protegiéndolo de la pérdida de datos.
Otras diferencias incluyen:
Múltiples repositorios “centrales”.
El código discrepante de los repositorios es fusionado sobre la base de una red de confianza. Por ejemplo, el histórico de méritos o calidad de cambios.
Numerosos modelos de desarrollo diferentes son posibles, como el desarrollo/lanzamiento de ramas de un modelo Comandante/Teniente, permitiendo la delegación eficiente del desarrollo de tópicos in proyectos de gran tamaño. Los tenientes son proyectos miembro que tienen la capacidad de decidir de forma dinámica qué ramas unificar (fusionar).
La red no está involucrada en operaciones comunes.
Un conjunto separado de operaciones de sincronización están disponibles para confirmar o recibir cambios con repositorios remotos.
Los propulsores del control de versiones distribuido señalan numerosas ventajas de los sistemas de control de versiones distribuido sobre el modelo centralizado tradicional:
Permite a los usuarios trabajar de forma productiva cuando no están conectados a la red.
Realiza las operaciones más rápido.
Permite la participación en proyectos sin requerir permiso de las autoridades, y por lo tanto fomenta la cultura de la meritocracia.
Permite el trabajo en forma privada, de modo que los usuarios pueden utilizar sus cambios incluso en iteraciones intermedias que no quieren publicar.
Evita confiar en una única máquina física como único punto de fallas.
Permite el control centralizado de las versiones de lanzamiento del proyecto.
En proyectos de software FLOSS es mucho más fácil crear una bifurcación del proyecto desde un proyecto que está detenido por los conflictos de liderazgo o desacuerdos en el diseño.
Joel Spolsky, autor dedicado al Desarrollo de Software y dueño de un sistema de control de versiones distribuido, describe el control de versiones distribuido como “posiblemente el más grande avance en tecnologías de desarrollo de software en (los últimos) diez años”.[1]
Una desventaja es que la clonación inicial de un repositorio es más lenta comparada a la centralizada, porque todas las ramas y el historial de revisiones son copiados. Esto puede ser significativo si la velocidad de acceso es lenta y el tamaño del repositorio es lo suficientemente grande. Por ejemplo, el tamaño del repositorio git clonado (todo el historial, ramas, etiquetas, etc.) del núcleo Linux es aproximadamente el tamaño del HEAD comprobado descomprimido, mientras la comprobación (checkout) equivalente de una única rama en una comprobación centralizada sería del tamaño comprimido del HEAD (exceptuando todo el historial, ramas, etiquetas, etc.). Otro problema del control de versiones distribuido es la cantidad de mecanismos de bloqueo que son parte de DVCS más centralizados y ocupan aun un rol importante cuando se trata de archivos binarios no fusionables como activos gráficos (graphic assets).
Referencias
Spolsky, Joel (17 de marzo de 2010). «Distributed Version Control is here to stay, baby». Joel on Software. Consultado el 18 de junio de 2010.
Datos:Q1186723
Agosto 06, 2021
control, versiones, distribuido, programación, informática, control, versiones, distribuido, permite, muchos, desarrolladores, software, trabajar, proyecto, común, necesidad, compartir, misma, revisiones, almacenadas, sistema, control, versiones, distribuido, . En programacion informatica el control de versiones distribuido permite a muchos desarrolladores de software trabajar en un proyecto comun sin necesidad de compartir una misma red Las revisiones son almacenadas en un sistema de control de versiones distribuido DVCS por sus siglas en ingles Distribuido vs Centralizado EditarEl control de versiones distribuido toma un enfoque entre iguales peer to peer opuesto al enfoque de cliente servidor de los sistemas centralizados En lugar de un unico repositorio central en el cual los clientes se sincronizan la copia local del codigo base de cada peer es un repositorio completo El control de versiones distribuido sincroniza los repositorios intercambiando ajustes conjuntos de cambios entre iguales Esto establece algunas diferencias importantes en comparacion a un sistema centralizado No existe una copia de referencia del codigo base por defecto solo copias de trabajo Operaciones comunes como commits visualizacion del historial y revertir cambios son rapidas porque no existe necesidad de comunicacion con un servidor central La comunicacion con el servidor solo es necesaria cuando se comparten cambios entre iguales peers Cada copia de trabajo funciona efectivamente como una copia de seguridad remota del codebase y de su historial de cambios protegiendolo de la perdida de datos Otras diferencias incluyen Multiples repositorios centrales El codigo discrepante de los repositorios es fusionado sobre la base de una red de confianza Por ejemplo el historico de meritos o calidad de cambios Numerosos modelos de desarrollo diferentes son posibles como el desarrollo lanzamiento de ramas de un modelo Comandante Teniente permitiendo la delegacion eficiente del desarrollo de topicos in proyectos de gran tamano Los tenientes son proyectos miembro que tienen la capacidad de decidir de forma dinamica que ramas unificar fusionar La red no esta involucrada en operaciones comunes Un conjunto separado de operaciones de sincronizacion estan disponibles para confirmar o recibir cambios con repositorios remotos Los propulsores del control de versiones distribuido senalan numerosas ventajas de los sistemas de control de versiones distribuido sobre el modelo centralizado tradicional Permite a los usuarios trabajar de forma productiva cuando no estan conectados a la red Realiza las operaciones mas rapido Permite la participacion en proyectos sin requerir permiso de las autoridades y por lo tanto fomenta la cultura de la meritocracia Permite el trabajo en forma privada de modo que los usuarios pueden utilizar sus cambios incluso en iteraciones intermedias que no quieren publicar Evita confiar en una unica maquina fisica como unico punto de fallas Permite el control centralizado de las versiones de lanzamiento del proyecto En proyectos de software FLOSS es mucho mas facil crear una bifurcacion del proyecto desde un proyecto que esta detenido por los conflictos de liderazgo o desacuerdos en el diseno Joel Spolsky autor dedicado al Desarrollo de Software y dueno de un sistema de control de versiones distribuido describe el control de versiones distribuido como posiblemente el mas grande avance en tecnologias de desarrollo de software en los ultimos diez anos 1 Una desventaja es que la clonacion inicial de un repositorio es mas lenta comparada a la centralizada porque todas las ramas y el historial de revisiones son copiados Esto puede ser significativo si la velocidad de acceso es lenta y el tamano del repositorio es lo suficientemente grande Por ejemplo el tamano del repositorio git clonado todo el historial ramas etiquetas etc del nucleo Linux es aproximadamente el tamano del HEAD comprobado descomprimido mientras la comprobacion checkout equivalente de una unica rama en una comprobacion centralizada seria del tamano comprimido del HEAD exceptuando todo el historial ramas etiquetas etc Otro problema del control de versiones distribuido es la cantidad de mecanismos de bloqueo que son parte de DVCS mas centralizados y ocupan aun un rol importante cuando se trata de archivos binarios no fusionables como activos graficos graphic assets Referencias Editar Spolsky Joel 17 de marzo de 2010 Distributed Version Control is here to stay baby Joel on Software Consultado el 18 de junio de 2010 Datos Q1186723Obtenido de https es wikipedia org w index php title Control de versiones distribuido amp oldid 129300650, wikipedia, wiki, leyendo, leer, libro, biblioteca,
