Usar SVN mal: ¿es Mercurial la respuesta?

En el trabajo usamos SVN, pero solo de nombre. No nos ramificamos ni fusionamos. Conservamos dos copias del repositorio, una que sirve como la rama de "etiqueta" que se copia cuando hacemos una implementación y la guardamos para la corrección de errores y el tipo inmediato de características "esto tiene que activarse lo antes posible". Debemos recordar copiar los cambios realizados en una copia a la otra copia (el "tronco"). Tenemos una docena de proyectos dentro de una sola carpeta en el repositorio, en lugar de dividirlos. En resumen, lo único para lo que usamos SVN es para poder comprometernos. Todo lo demás se hace manualmente.

He estado evaluando Mercurial; He usado Git en el pasado (soy el único en el equipo que ha usado un DVCS), y estoy recogiendo Mercurial rápidamente. Estoy debatiendo la presentación de Mercurial al resto del equipo como una "mejor manera" de hacer las cosas porque ramificar es muy fácil, la fusión es mucho más fácil y podemos comprometer las cosas localmente al contenido de nuestro corazón y solo llevarlos al centro bifurca cuando estén listos. Obtendríamos todos los beneficios de SVN (y de todos modos no estamos obteniendo muchos beneficios en este momento, ya que nadie realmente entiende SVN), además de las nuevas características no tenemos que tener toneladas de archivos no versionados flotando, así que si tenemos que retroceder estamos jodidos. El flujo de trabajo parece un poco más simple: solo tenemos que recordar que "Commit" es local y "Push" es como el commit de SVN,

¿Es este un buen enfoque? Tenga en cuenta que el equipo es muy flexible y aceptará cualquier cosa que mejore nuestra calidad de trabajo y facilite la forma en que hacemos las cosas: el CIO incluso me preguntó cuando mencioné cómo no estábamos usando SVN para su potencial "Es hay algo mejor que podamos usar? así que él también está a bordo.

Si.

Si reemplaza "SVN" con "Perforce" en su OP, tiene la situación en la que me encontraba cuando comencé mi trabajo actual, incluso hasta la copia de cambio manual. Dos años después estamos en Mercurial y todos están de acuerdo en que ha sido un gran cambio.

Tenemos la capacidad de ramificar y fusionar por caso de soporte , lo cual es increíblemente útil para el control de calidad, y la capacidad de crear cualquier cantidad de ramas y repositorios desechables cuando lo creamos conveniente, que luego podemos construir y verificar en nuestro servidor de CI, luego implementar a un entorno de prueba en la nube y verificar la funcionalidad. Esto ha sido de gran beneficio en términos de tranquilidad de que cuando hacemos una implementación en vivo, estamos casi 100% seguros de que funcionará (sin problemas de entorno / DB, que obviamente están fuera del alcance del VCS).

Básicamente, lo que ganamos al cambiar a mercurial es respirar espacio. Ya no tenemos que preocuparnos por el costo de una sucursal, o las horribles sesiones de fusión que inevitablemente solían seguir, todo es mucho más fácil. También usamos FogBugz con bastante frecuencia, por lo que la conexión con Kiln (su mercurial alojado) es realmente útil.

El comentario sobre el sitio hginit también es perfecto , como un esquema para un flujo de trabajo de control de versiones que realmente funciona (suponiendo que lo ajuste para el flujo de trabajo de control de calidad particular de su empresa).

El único defecto posible en los controles de versión en movimiento es que necesitará a alguien que realmente sea una fuerza impulsora detrás del cambio, que esté feliz de leer sobre el tema y realmente use las herramientas lo mejor que pueda, lo que parece querer hacer.

Tampoco estoy de acuerdo con los comentarios sobre el tamaño del equipo y la distribución del equipo en relación con el uso de DCVS. Realmente, se trata de la distribución del CÓDIGO. Si tiene múltiples ciclos de desarrollo que ocurren en paralelo, ya sea casos de soporte en un sistema heredado, o un montón de características o incluso nuevos sistemas (que por lo que parece), se beneficiará al usar un DVCS.

Probablemente, una herramienta diferente no va a resolver su problema. Diría que debería leer este artículo, lo encontré más útil:

http://thedailywtf.com/Articles/Source-Control-Done-Right.aspx

Creo que el punto principal del artículo se resume aquí, pero léalo:

Al final: no realmente sobre las herramientas

En todo el tiempo que he pasado trabajando e integrando diferentes sistemas de control de fuente, he llegado a una conclusión: no es la herramienta, es cómo la usas. Esa es una declaración terriblemente trillada, pero parece especialmente cierto aquí. Cuando se usa para administrar adecuadamente los cambios en el código fuente (etiquetado para compilaciones, ramificación por excepción, etc.), incluso el último sistema de control de fuente (* tos * SourceSafe * tos *) superará con creces una configuración de Mercurial con un montón de confirmaciones al azar y empuja

No. La tecnología rara vez resuelve este tipo de problema.

Mercurial es más complejo que Subversion (sí, ramificar y fusionar es mejor, y quizás más fácil, pero el modelo de Subversion es mucho más simple que el de Mercurial). Si está utilizando Subversion de tal manera, puede terminar usando Mercurial:

• a) Adecuadamente o mejor
• b) Inadecuadamente, pero mejor que su uso actual de Subversion
• c) Tan inadecuada como ahora
• d) Peor que ahora

c) yd) suenan como los resultados más probables. Escribe por qué crees que terminarás en a) ob).

No puedo hablar sobre cómo funcionan los equipos grandes, pero para los equipos pequeños, muchos de esos grandes problemas de SVN no son realmente problemas de SVN ... Son problemas de desarrollo. Si no está siguiendo los estándares de desarrollo modernos (lo más importante, haciendo una integración continua), entonces el control de versiones se convierte en el desastre exacto que está describiendo ... Antes de saltar a un nuevo sistema, asegúrese de realizar un verdadero análisis de causa raíz en su problema ...

No. Las herramientas no reemplazan la metodología.

Si no usa Subversion como SCM , no puede usar Mercurial también (y sucederá muy probablemente)

SVN puede hacer lo que necesita hacer y no hay necesidad de cambiar caballos a mitad de camino para obtener un pago dudoso.

Hagas lo que hagas, tendrás que superar un problema de confianza. Alguien tiene que poder convencer a todos de cambiar su flujo de trabajo. Esto no es fácil incluso en las mejores circunstancias, incluso si tiene la lógica y los hechos de su lado. Es una de las cosas más difíciles de hacer en una organización. Si lo estropea o se vuelve rudo, pierde confianza y será muy difícil recuperar esa confianza.

Hay un par de cosas que sé que la gente ha intentado con éxito. Quizás uno de ellos funcione para su equipo:

1. Traiga un "entrenador" para proporcionar una serie de talleres para el equipo. Es probable que tenga que ser una persona externa (irónicamente, a menudo es más fácil para muchos equipos confiar en un extraño que confiar en alguien del equipo). Tiene que ser alguien que conozca sus cosas al revés y que pueda enseñar estas habilidades de manera efectiva a las personas en todos los niveles de comprensión e idear un plan pragmático para implementar el nuevo VCS (*) en el flujo de trabajo del equipo.

2. Inicie un proyecto "skunk-works" para probar y validar el nuevo VCS en un pequeño proyecto paralelo. Elija un par de desarrolladores "alfa" que estén dispuestos a probar cosas nuevas y no les importe acumular un montón de experimentos fallidos. Cuando Skunk-Works puede demostrar mejoras irrefutables de CONCRETE en el flujo de trabajo, entonces puede intentar implementarlo para el resto del equipo y tiene un par de evangelistas para ayudarlo a hacerlo.

(*) por "nuevo VCS" no necesariamente me refiero a mercurial o git, también puede ser SVN (hecho bien).