Busqué y no pude encontrar ninguna razón comercial por la cual los sistemas git / mercurial / bazzr son mejores que los sistemas centralizados (subversión, rendimiento).

Si intentara vender un DVCS a una persona no técnica, ¿qué argumentos proporcionaría para que el DVCS aumente las ganancias ?

En breve estaré lanzando git a mi gerente, llevará algún tiempo convertir repositorios de subversión y algunos gastos en la compra de licencias de smartgit.

Editar Traté de hacer esta pregunta en una discusión genérica sobre centralizado vs descentralizado, pero inevitablemente se ha convertido en git vs subversion. Seguramente hay mejores sistemas centralizados que la subversión.

Hmm, después de haber sido gerente, tengo dos reacciones inmediatas a esto:

• Si aún no tienes buenas razones, ¿por qué estás lanzando git aparte de estar a la moda?
• Del mismo modo, ¿cómo está fallando Subversion de tal manera que necesita un reemplazo?

En realidad, no estoy siendo negativo: creo que es probable que exista un caso (dependiendo de las circunstancias), pero si el caso es simplemente que git es "mejor" que la subversión, entonces realmente no tienes uno.

También debe ser capaz de enumerar las desventajas (ya ha identificado la sobrecarga de la migración y las nuevas herramientas), ¿qué más es un problema? Por ejemplo, ¿qué le sucede a su repositorio agradable, central y respaldado? ¿Cómo se integra con su servidor de compilación de integración continua (si no tiene uno, olvide git y ordene eso primero). Oh seguridad y seguimiento: SVN se ejecuta con los inicios de sesión y permisos adecuados.

En mi opinión, los beneficios están en la flexibilidad, la mejor fusión, la capacidad de realizar compromisos locales sin romper la compilación, etc. Las desventajas son la falta de control y la misma flexibilidad.

Es posible que todo lo que quiera hacer sea ejecutar git localmente en su máquina como un "mejor" cliente de subversión (estoy buscando hacerlo usando mercurial).

Hmm, ¿tal vez toda esta respuesta es realmente un comentario? Debe presentar su caso aquí (en la pregunta) para git over subversion (en su entorno) para ver si podemos ayudarlo a identificar el caso comercial.

FWIW, sé que uno puede designar fácilmente una instancia específica del repositorio para que sea la fuente troncal / de referencia y, además, esa es la forma en que uno se conecta al servidor de compilación, la diferencia es que con DVCS es más una decisión administrativa que algo inherente a la arquitectura.

Diría que la ramificación y fusión rápidas e indoloras permitiría a los desarrolladores ser más productivos con su código, ya que cada nueva característica podría ramificarse y luego fusionarse. Hacer que el proceso de desarrollo transcurra mucho más fácilmente. Además, la naturaleza distribuida permitiría a cada desarrollador tener una copia completa del código, por lo que no hay que preocuparse de que una falla del servidor centralizado elimine todo su código. Probablemente haya más razones, esas dos, sin embargo, son mis principales razones para usar Git.

Supongo que puede defender el control de versiones para aumentar la productividad (y, por lo tanto, las ganancias) incluso cuando un desarrollador está trabajando solo.

Un buen DVCS reconoce esos mismos beneficios de productividad incluso cuando trabaja como parte de un equipo: cada desarrollador puede obtener todos los beneficios de trabajar con el control de versiones; pueden realizar compromisos frecuentes, retrocesos, jugar con cosas, etc., sin preocuparse por los conflictos con lo que otros desarrolladores están haciendo hasta que estén listos para impulsar sus cambios.

• Rama por error
• Latencia reducida en sus diferencias.
• Ser capaz de navegar muy rápidamente de manera arbitraria a través del historial de una sucursal cuando realiza una revisión por pares.
• Todavía tiene acceso a su historial completo cuando no tiene acceso al servidor centralizado: no está en la oficina, se acabó la energía pero la batería de su computadora portátil sigue funcionando ...

Estas cosas le permiten trabajar de manera más eficiente, tanto en solitario como en equipo. Trabajo más eficiente = tiempo de desarrollo más rápido = tiempo de comercialización más rápido = beneficio.

Perdóname por vincularme a mi propio blog, pero he escrito artículos sobre este mismo tema:

• Por qué la sugerencia siempre debe compilarse
• ¿Por qué DVCS proporciona un mejor control central?
• ¿Por qué es mejor ramificar con DVCS?
• Por qué los modelos de ramificación distribuida pueden no funcionar bien en su CVCS .

Siéntase libre de votar si no los encuentra relevantes.

En pocas palabras, DVCS facilita la ramificación de modelos que pueden evitar que grandes grupos de desarrolladores se pisen los pies, lo que aumenta tanto la productividad como la calidad de construcción diaria. La parte de colaboración desordenada del control de versiones se puede hacer en repositorios locales, dejando su repositorio central más limpio y de mayor calidad. Además, las decisiones sobre cuándo ramificarse pueden tener un gran efecto en la eficiencia, por ejemplo, si un departamento está listo para comenzar a trabajar en 2.0 cuando otros todavía están limpiando 1.0. DVCS permite que esas decisiones se tomen a nivel local en lugar de por comité.

Mis argumentos para DVCS son estos:

• La ramificación no está rota, lo que conduce a una menor fricción en el desarrollo de características y el mantenimiento de los productos existentes parcheados. La fricción cuesta dinero a tiempo.

• Pasar a un sistema moderno atrae mejor a los desarrolladores de vanguardia, lo que conducirá a una cultura de mejores productos, que le permite a la empresa vender más productos.

• Las confirmaciones que no son de red son más rápidas , lo que permite que los desarrolladores se comprometan a menudo, lo que lleva a la detección y análisis de errores específicos.

Básicamente, se trata de reducir la fricción. Hay un término para esto: Muda . Cuanto más fricción, más dolor es hacer cosas. Cuanto más dolor, menos se hace, menos ganancias.

Pido disculpas si soy soberbio, pero permítanme exponer el caso comercial en términos inequívocos:

SVN hace que la vida de los desarrolladores sea miserable . Y eso hace que un negocio de software sea miserable.

... de maneras que muchos no se darán cuenta hasta que comiencen a usar un DVCS. Este es el caso comercial más importante que posiblemente se pueda hacer . ¿Por qué? Bueno, en comparación con el costo de encontrar y retener buenos desarrolladores, el costo de cambiar a un DVCS es casi inexistente .

Considera lo siguiente:

• Todas las operaciones, excepto las más triviales, en SVN (y la mayoría de los otros CVCS) requieren acceso a la red. En la mayoría de DVCSes, acceso a la red sólo se produce cuando se hace una pusho pullfuncionamiento. Esto significa que los comandos no triviales son lentos . ¿Qué haces cuando un comando toma para siempre? Yo personalmente voy a navegar por programmers.se o las noticias de hackers mientras espero. En pocas palabras, los DVCS permiten a los programadores centrarse en hacer lo que aman: escribir el software de la compañía .
• SVN tiene soporte para ramificarse de la misma manera que las cárceles tienen soporte para dejar caer el jabón en la ducha: puedes hacerlo, pero cuando lo haces te follan. Por lo tanto, SVN obliga a sus desarrolladores a luchar constantemente entre sí para realizar cambios .
• Cuando SVN está inactivo, está inactivo. Se vuelve terriblemente difícil para los desarrolladores hacer su trabajo si pueden hacerlo. Por lo tanto, SVN obliga a sus desarrolladores a depender de que su infraestructura esté 100% libre de errores .
• En estos días, git está ganando rápidamente la mente compartida mientras SVN lo está perdiendo rápidamente. Si no hay beneficios al usar DVCSes sobre SVN, ¿por qué la comunidad de programación está cambiando tan rápido como pueden?

¿Qué significa todo esto? Todavía tengo que encontrarme con un desarrollador que le haya dado una prueba honesta a DVCS que preferiría SVN después. Si pudiera hacer una declaración más molesta y en negrita, SVN es un "mal necesario" que los desarrolladores se obligan a usar. Git es una herramienta que hace que los desarrolladores sean más productivos y felices .

(Debo señalar que las declaraciones en negrita son las particulares en las que debe centrarse. El resto de ellas solo proporcionan contexto).

Lo único en lo que puedo pensar es que git funciona sin una conexión de red. A menudo, todo lo demás es difícil de vender a usuarios técnicos que usan subersión o rendimiento por bastante tiempo.

La diferencia se muestra cuando hay problemas

Cambiamos a git hace 6 meses después de portar nuestro repositorio de una década.

Hasta ahora he encontrado lo siguiente, después de un poco de experimentación:

• La ramificación y fusión es casi indolora. Esto hace que sea mucho más fácil trabajar en funciones separadas y corrección de errores sin pisar los dedos de los demás. También hace que sea muy fácil aplicar una corrección de error dada en otro lugar también.

• más robusto por diseño: no confía al 100% en la disponibilidad de un servidor central, y si no lo está, puede usar promocionar cualquier clon temporalmente como un reemplazo activo. Esto elimina un punto crucial de falla: si el servidor SVN se cae por algún motivo, nadie puede hacer el trabajo SVN. Si el repositorio central de git se cae por algún motivo, aún puede trabajar y presionar / tirar localmente para asegurarse de que las confirmaciones se replican. Incluso puede tener múltiples repositorios fuera del sitio exactamente para este propósito.

• La interacción del repositorio se simplifica. Para CVS, esencialmente necesitaba acceso todo el tiempo en cualquier momento que necesitara alguna información. Para git, todo el repositorio está disponible localmente, lo que permite que muchas cosas vayan más rápido.

Por lo tanto, el beneficio no es tanto en la rutina diaria, ¡pero es muy claro en el momento en que algo no funciona correctamente!

Por lo tanto, sugiero que para su caso de negocios, mire lo que hará cuando ocurra un desastre ...

La facilidad de ramificación y fusión es la razón más concreta, pero para convencer a alguien tendrá que darles un ejemplo concreto de cómo eso mejora las cosas.

Supongamos que tiene algunos programadores trabajando en mejoras de rendimiento para una aplicación, y están en la etapa experimental y no saben si el código que están escribiendo alguna vez formará parte de la rama maestro / troncal. Sin embargo, necesitan compartir código con frecuencia entre sí y probar ideas que pueden ser callejones sin salida. ¿Cómo manejas la ramificación y fusión tan frecuente en subversion? La respuesta corta es que no. Con un dvcs es realmente fácil, y los programadores pueden probar rápidamente nuevas ideas en ramas y compartirlas con otros antes de decidir si esa idea se mantendrá.

El argumento comercial para deshacerse de SubVersion es que el soporte de ramificación es una barrera para la estabilización y el mantenimiento del producto. Si necesita lanzar un producto y luego continuar con el desarrollo, necesita una rama. Con Subversion, los desarrolladores no utilizarán la ramificación correctamente, por lo que no podrá mantener el desarrollo en el tunk y se asegurará de que las correcciones de errores realmente lleguen tanto al tronco como a la rama.