Si mi equipo tiene dificultades para hacer las cosas bien en Subversion, ¿pueden tener éxito con Git o Mercurial?

Gracias por el A2A. No conozco Mercurial, pero sí conozco Subversion y Git, y entiendo que Mercurial es esencialmente Git escrito en Python con una interfaz un poco más amigable, así que si estás considerando Mercurial, aplica mis comentarios sobre Git en consecuencia.

La respuesta a esto depende de los detalles. La ramificación / fusión en Subversion 1.8 es más lenta que en Git por definición porque ocurre en una red. Sin embargo, para el caso de uso más común de las ramas (compilación candidata o compilación de características), debería funcionar bien. Si haces un montón de ramificaciones y fusiones, Git te ahorrará tiempo a largo plazo.

Si las personas tienen problemas para generar compilaciones limpias, eso suena como un problema con el proceso, no con la herramienta. Haría preguntas como:
¿Qué marcos de prueba utilizan los equipos? Las pruebas insuficientes son una causa común de compilaciones rotas. Es difícil lograr una cobertura del 100% del código, pero puede crear fácilmente pruebas en la mayoría de los idiomas modernos para detectar problemas y, en particular, verificar que una característica no tenga regresiones o errores obvios.
¿Cuán precisos son los entornos personales de su equipo? Con máquinas virtuales, Docker, etc., no hay una buena excusa para que la mayoría de los equipos eviten tener un entorno para implementar para verificar los cambios de código antes de implementarlos en un entorno compartido. Cada hora que dediques a configurar esto te compensará con al menos dos horas de esfuerzo reducido en el back-end.
¿Qué permisos tienen las personas para cambiar el código de producción? Esta es un área donde Subversion es más fácil de usar que Git. Subversion admite permisos específicos en directorios, y dado que las ramas son directorios en Subversion, puede bloquear ramas y asegurarse de que el acceso al código de producción esté controlado. Git tiene algunas cosas que se pueden aplicar para bloquear ramas, pero en última instancia, está diseñado para administrar bases de código como el kernel de Linux, que tienen un desarrollo masivamente paralelo y tienen una noción débil de maestro.

Si conoce las respuestas a estas preguntas, sabrá por qué su equipo tiene problemas de desarrollo. Lo más probable es que no estén probando lo suficiente, no tengan un buen lugar para ver su código ejecutándose antes de que sea promovido, o el equipo está promoviendo código no probado demasiado pronto.

Ramificar y fusionar en subversión es difícil porque las herramientas son lentas (diff) y engorrosas de usar (fusionar), por lo que si tiene un flujo de trabajo que necesita ramificación y fusión, estará mucho mejor con git.

Dicho esto, otra alternativa que podría considerar es capacitar a un número menor de personas en el uso de git-svn y otorgarles responsabilidades de fusión. Esto permite que la mayor parte del equipo continúe usando el SVN familiar, pero le permite obtener algunos (pero no todos) los beneficios de git.

Personalmente, he usado este enfoque con un equipo relativamente grande de desarrolladores.

Esta pregunta es un poco como decir “Me cuesta mucho hacer girar mi fonógrafo, ¿puedo tener éxito con un nuevo reproductor de MP3”?

En otras palabras, mundos diferentes, marcos diferentes, modelos diferentes, géneros diferentes: el último construido para hacer el desarrollo más fácil que su predecesor … ¡así que carpe diem!

Lo primero que el equipo necesita saber es una comprensión de alto nivel de las diferencias entre un repositorio centralizado (SVN, Perforce, etc.) versus descentralizado (Git, Mercurial).

Aquí hay una revisión del concepto: CVCS vs. DVCS en pocas palabras: proporciona una visión general de POR QUÉ deberían / ​​podrían / ​​deberían migrar a un entorno DVCS.

A continuación, ponte en marcha lo menos doloroso posible. Atlassian Hosted BitBucket o GitHub: nuevas cuentas en 2 minutos. De hecho, es una buena idea que TODOS sus desarrolladores tengan una cuenta privada / personal gratuita de todos modos, así que anímenlo: obtenga una cuenta en ambos servicios si lo desea. Te traerá más buy-in.

Arme a su equipo con este tutorial Git Basics y las docenas más disponibles por ahí. ¡Google es tu amigo!

Para la empresa, actualice Bitbucket o GitHub o compre las versiones locales, Atlassian Stash o Enterprise Github. Pruebe antes de comprar. Aquí hay un tutorial sobre migración.

Obtener el buy-in es el 95% de la razón para tener éxito aguas abajo, sinceramente. Así que solo hazlo, discute y migra lentamente si todos están de acuerdo. Pero solo tienes que ir por ello.

Aquí hay un par de publicaciones excelentes para respaldar aún más tu camino:

  • Evidencia empírica de popularidad de Git y Mercurial
  • Control de versiones centralizado vs descentralizado: 2010 vs 2012

Nuestro flujo de trabajo está diseñado de tal manera que la ramificación y la fusión se limitan a unas pocas personas con experiencia. La mayoría está usando subversión solo para confirmar y actualizar.

Tienes que cambiar el flujo de trabajo o migrar a git, que es más fácil de combinar. Aunque no estoy seguro acerca de la parte fácil de usar en caso de que sus usuarios no sean muy buenos en la línea de comandos.

Sí, git es genial para hacer estas cosas, puede configurar un repositorio en bitbucket.org de forma gratuita o en github, es fácil de aprender, bitbucket proporcionará todas las herramientas que necesita para administrar fácilmente a un costo simple, pueden ser hecho gratis también, svn trajes para mejor es solo persona está manejando, para los esfuerzos del equipo ir con git. Y puede implementar con git directamente en el proyecto con la ayuda de fabric, una biblioteca para python