version-control - tipos - sistemas distribuidos ppt
Control de fuente: sistemas distribuidos vs. no distribuidos: ¿cuál es la diferencia? (6)
Acabo de leer el último artículo de Spolsky sobre sistemas de control de versiones distribuidas y no distribuidas http://www.joelonsoftware.com/items/2010/03/17.html . ¿Cuál es la diferencia entre los dos? Nuestra empresa usa TFS. ¿En qué campamento cae esto?
La diferencia está en el proceso de publicación:
- un CVCS (Centralizado) significa: para ver el trabajo de su colega, debe esperar a que publiquen (confirmen) en el repositorio central. Luego puede actualizar su espacio de trabajo.
- Eres un productor activo : si no publicas nada, nadie ve nada.
- Usted es un consumidor pasivo : descubre nuevas actualizaciones cuando actualiza su espacio de trabajo y tiene que lidiar con esos cambios, lo quiera o no.
.
- un DVCS significa: no hay "un repositorio central", pero cada espacio de trabajo es un repositorio, y para ver el trabajo de su colega, puede consultar su repositorio y simplemente pasar su historial a su repositorio local.
- Usted es un productor pasivo : cualquiera puede "enchufar" en su repositorio y hacer comprobaciones locales que hizo en su propio repositorio local.
- Usted es un consumidor activo : cualquier actualización que saque de otro repositorio no se integra inmediatamente en su rama activa a menos que lo haga explícitamente (a través de fusión o rebase).
Version Control System trata de dominar la complejidad de los cambios en los datos (debido a tareas paralelas y / o trabajos paralelos en una tarea), y la forma en que colaboras con otros (otras tareas y otras personas) es bastante diferente entre un CVCS y un DVCS.
TFS ( Team Foundation Server ) es un sistema de gestión de proyectos que incluye un CVCS: Team Foundation Version Control (TFVC), centrado en la noción de "elemento de trabajo".
Su aspecto centralizado impone una coherencia (de otros elementos aparte de las fuentes)
Ver también este documento de VSS a TFS , que ilustra cómo se adapta a un equipo que tiene acceso a un referencial.
Un referencial significa que es más fácil de mantener (no se necesita sincronización ni actualización de datos), por lo tanto, la mayor cantidad de elementos (listas de tareas, planes de proyectos, problemas y requisitos) que se manejan en él.
Simplemente hablando, un sistema centralizado de VCS (incluido TFS) tiene un almacenamiento central y cada usuario obtiene y se compromete con esta ubicación.
En VCS distribuido, cada usuario tiene el repositorio completo y puede realizar cambios que luego se sincronizan con otros repositorios; por lo general, un servidor no es realmente necesario.
Un VCS centralizado (CVCS) implica un servidor central con el que se interactúa. Un VCS distribuido (DVCS) no necesita un servidor centralizado.
Las cajas de DVCS son completas y autónomas, incluido el historial de repositorios. Este no es el caso con CVCS.
Con un CVCS, la mayoría de las actividades requieren interactuar con el servidor. No ocurre lo mismo con DVCS, ya que son pagos "completos", historial de repositorios y todo.
Necesita acceso de escritura para comprometerse con un CVCS; los usuarios de DVCS "tiran" de los cambios entre sí. Esto lleva a una codificación social más facilitada por gente como GitHub y BitBucket.
Esos son algunos artículos relevantes, sin duda hay otros.
Visita http://hginit.com . Joel escribió un buen tutorial para Mercurial, que es un DVCS. No había leído antes sobre DVCS (siempre he usado SVN) y me resulta fácil de entender.
Recomiendo leer la crítica de Martin Fowler sobre las herramientas de control de versiones
En resumen, la diferencia clave entre CVCS y DVCS es que los primeros (de los cuales TFS es un ejemplo) tienen un repositorio central de código y en el último caso, hay varios repositorios y nadie es ''por defecto'' el central. son todos iguales
La diferencia es enorme
En sistemas distribuidos, cada desarrollador trabaja en su propia caja de arena; él tiene la libertad de experimentar todo lo que quiera, y solo acceder al repositorio "principal" cuando su código está listo.
En sistemas centrales, todos trabajan en la misma caja de arena. Esto significa que si su código no es estable, no puede verificarlo, porque romperá el código de todos los demás.
Si está trabajando en una función, demorará un tiempo antes de que se estabilice, y como no puede permitirse el compromiso de un código inestable, se sentará en los cambios hasta que se estabilice. Esto hace que el desarrollo realmente sea muy lento, especialmente cuando hay muchas personas trabajando en el proyecto. Simplemente no puede agregar nuevas funciones fácilmente porque tiene este problema de estabilización en el que desea que el código en el enlace sea estable pero ¡no puede!
con sistemas distribuidos, dado que cada desarrollador trabaja en su propio entorno limitado, no necesita preocuparse por desordenar el código de otra persona. Y debido a que estos sistemas tienden a ser muy buenos para fusionarse, aún puede tener su base de código actualizada con el repositorio principal mientras mantiene los cambios en su repositorio local.