2009-03-31 16 views
10

Parece que muchas personas leen sobre el control de versiones distribuidas y entienden implícitamente por qué es bueno para el desarrollo de código abierto, y muchos desarrolladores distribuidos actúan de forma independiente y de acuerdo con sus propias elecciones en lugar del mandato de la administración. Pero a partir de esta impresión, muchas personas forman la idea de que DVCS es útil solo en un entorno de código abierto; no pueden ver cómo podría ayudar a una organización que lanza un producto patentado y no hace que su sistema de control de versiones sea accesible externamente, o cómo podría ayudar a un solo desarrollador.¿Por qué debería una empresa usar control de versión distribuida?

¿Cuáles son algunos de los beneficios que una empresa puede ver si elige usar control de versión distribuida como git, darcs o Mercurial en lugar de control de versión centralizada como CVS o Subversion?

Respuesta

5

En primer lugar, un DVCS no impide que un código de gestión centralizada: todavía se puede establecer un repositorio como la "referencia", todos los desarrolladores tirando de ella.
Así que el beneficio (un efecto secundario en realidad) aquí es una copia de seguridad natural a través de la replicación de datos, mientras se mantiene una base de código central.

Pero el verdadero beneficio proviene del desarrollo cruzado entre proyectos: es decir, cuando se necesitan desarrollos "del otro equipo, del otro proyecto", para que su trabajo avance: puede sacar fácilmente uno trabajando en la rama de su repositorio (rastreándolo), sin tener que esperar a que lo publiquen oficialmente en el repositorio central.

Eso significa que incluso con el depósito sólo se replican internamente (dentro de una empresa), que aún así obtener la ventaja principal de un DVCS, a saber, la facilidad de seguimiento, tirar y la fusión de las ramas de repositorios locales y diversas, mientras que con un principal base donde publicar su código para el resto del ciclo de vida de desarrollo.
(todas las pruebas de integración, homologación y preproducción se ejecutarán únicamente desde códigos publicados en ese depósito central).

También se puede ver con un DVCS manejado de esa manera un proceso natural de "limpieza" (solo lo que es "válido" -al menos probado por ejemplo- se publica en el repositorio central), con un historial más limpio (todas las confirmaciones intermedias pueden permanecer en las ramas temáticas de los repositorios locales).

0

No veo por qué es mejor para el desarrollo de código abierto. Los proyectos comerciales tienen muchos desarrolladores que trabajan en cosas diferentes al mismo tiempo, también. ¿Su "mandato de la administración" le indica qué archivos editar y cuándo?

1

Una cosa que he notado es que el uso de Mercurial que ha cambiado mi forma de trabajar, incluso localmente en mi estación de trabajo. La idea de que cada copia es un repositorio completo e independiente se presta para mantener diferentes copias con trabajos diferentes y fusionarlas juntas o en el repositorio "común". Eso es bueno porque los conjuntos de parches para cosas diferentes permanecen juntos, además de mantener el trabajo separado. Estas cosas se pueden hacer de alguna manera en los sistemas tradicionales, pero en Mercurial es natural. Ofrecer más flexibilidad en la organización del flujo de trabajo también tiene otros beneficios.

11

El argumento parece estar retrógrado para mí.

Teniendo en cuenta que un sistema de control de versiones centralizado es sólo uno de muchos casos de uso de un sistema distribuido, ¿cómo aplicar una restricción de este tipo en beneficio de la empresa?

Sé por experiencia que cuando un servidor p4 se pone lento o se rompe o se aleja demasiado de él o algo, todo el mundo que lo está usando debe dejar de funcionar.

A la gente le gusta tratar el argumento del "avión" como un poco de un hombre de paja, pero he estado allí donde realmente importaba. En el sitio en un evento de interoperabilidad o demostración de cliente donde tenemos que construir algo ahora en un entorno con soporte de red limitado y todo ese trabajo tiene que volver y Quiero poder revertir cuando cometo errores.

Los dos argumentos que he escuchado no suena bien para mí:

  1. no puede tomar todo el código y ejecutarlo.
  2. bloqueando

número 1 es una estupidez. Tal vez es ligeramente más difícil para obtener el historial completo (y si no puedo, no hay un sistema de control de revisión de todos modos), pero cuando se trata del tipo de miedo del que estamos hablando aquí, puedo tomar el último revisión y es igual de peligroso.

El número 2 realmente parece tratar de usar la herramienta incorrecta para el trabajo. Solía ​​obtener argumentos anti-CVS de los usuarios RCS porque realmente pensaban que debería bloquear cada archivo cada tiempo para evitar que dos personas, no sé, funcionen.

La comunicación está fuera de banda. Si tiene archivos grandes y no fusionables, está bien hablar de ellos, creo. OMI, muchas de las personas con este problema no quieren un sistema de control de revisiones, sino un sistema de archivos de instantáneas (zfs, 9fs, Drop Box, etc.).

En general, sin embargo, no entiendo por qué las personas incluso preguntan: "¿Por qué debería darle a mis desarrolladores herramientas más baratas, más rápidas, más confiables, más robustas y más productivas?" tipos de preguntas.

+1

"¿Cómo funciona la aplicación de una restricción de este tipo en beneficio de la sociedad", no creo que lo haga, pero que planteo esta cuestión como si se trata de una nueva organización de la marca ... Para un equipo de desarrollo grande, la pregunta es si vale la pena o no el esfuerzo de pasar de sus vcs existentes. Es una opción mucho más fácil cuando tienes un equipo muy pequeño o una empresa completamente nueva. –

5

Estoy de acuerdo con VonC, pero me gustaría añadir que (al menos en git) es trivial para hacer nuevas sucursales donde puedo trabajar fácilmente en código experimental o prototipos que no necesariamente quiero compartir con el resto de los usuarios del repositorio. Esto ayuda a mantener limpio el repositorio central (si usa uno) y creo que libera a los desarrolladores para probar cosas que de otro modo no intentarían en un sistema en el que corren el riesgo de poner código experimental en el repositorio central.

También he notado que trabajar en múltiples sucursales con git es mucho más productivo ya que el intercambio entre sucursales es rápido y no tengo que realizar varias transferencias a la vez en directorios separados.

3

Con git hay una serie de puentes para los sistemas basados ​​en repositorios centrales tradicionales.

Encuentro que git es un cliente superior para svn que para el propio svn, por ejemplo. Entonces, si la compañía insiste en usar un sistema de repositorio central, aún puede obtener los beneficios personales de git mientras mantiene el repositorio central.

+0

Tengo mucha flexibilidad cuando trato con repositorios svn centrales solo usando git localmente de mi lado, y teniendo un gran manejo de fusión proporcionado por git en lugar de tener que lidiar con el horror de las fusiones en svn. – Kzqai

0

Comprobar las ventajas más aquí ...

http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git 

http://www.ehow.com/info_12217814_git-commit-vs-push.html 
Cuestiones relacionadas