El uso de SVN es deficiente: ¿es Mercurial la respuesta?

Sí.

Si reemplaza "SVN" por "Perforce" en su OP, tiene prácticamente la situación en la que me encontré 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 dividir y fusionar por caso de soporte , que es increíblemente útil para el control de calidad, y la capacidad de crear cualquier número de sucursales y repositorios desechables siempre que lo creamos, lo cual podemos cree y verifique en nuestro servidor de CI, luego implemente en un entorno de prueba en la nube y verifique la funcionalidad. Esto ha sido de gran beneficio en términos de tranquilidad, ya 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 de El alcance del VCS).

Básicamente, lo que ganamos al cambiar a mercurial es el espacio para respirar. 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 utilizamos FogBugz bastante, por lo que la conexión con Kiln (su mercurial alojada) es realmente útil.

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

La única falla 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 usar las herramientas al máximo de su potencial, lo que parece querer hacer.

Tampoco estoy de acuerdo con los comentarios sobre el tamaño del equipo y la distribución del equipo con respecto a si usar DCVS. Realmente, se trata de la distribución de CÓDIGOS. Si tiene varios ciclos de desarrollo en paralelo, ya sea que admita casos en un sistema heredado, o un conjunto de características o incluso sistemas nuevos (que, por el sonido que haga), se beneficiará del uso de un DVCS.

Es probable que una herramienta diferente no solucione el problema. Yo diría que debería leer este artículo. Lo encontré más útil:

enlace

Creo que el punto principal del artículo se resume aquí, pero por favor, 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 el   herramienta, es como la usas Esa es una declaración terriblemente trillada, pero   Parece especialmente cierto aquí. Cuando se utiliza para gestionar correctamente la fuente   cambios de código - etiquetado para construcciones, bifurcaciones por excepción, etc. -   incluso el sistema de control de fuente más modesto (* tos * SourceSafe * tos *) lo hará   superan con creces una configuración de Mercurial con un montón de compromisos aleatorios   y empuja.

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

Mercurial es más complejo que Subversion (sí, la ramificación y fusión 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 forma tan inteligente, podría terminar usando Mercurial:

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

c) yd) parecen los resultados más probables. Escriba por qué cree que terminará en a) o b).

No puedo hablar de 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 es que realiza una integración continua), el control de versiones se convierte en el lío exacto que está describiendo ... Antes de pasar a un nuevo sistema, asegúrese de realizar un verdadero análisis de causa raíz en su problema. ...

No. Las herramientas no son reemplazo de la metodología.

Si no usa Subversion como SCM , puede no use Mercurial también (y es muy probable que ocurra)

SVN puede hacer lo que necesite y no hay necesidad de cambiar de caballo a mitad de camino para una dudosa recompensa.

Hagas lo que hagas, tendrás que superar un problema de confianza. Alguien tiene que poder convencer a todos para que cambien 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 arruinas o se vuelve difícil, pierdes la 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 tu equipo:

1. Traiga un "entrenador" para proporcionar una serie de talleres para el equipo. Es probable que esto 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 desde adentro y que pueda enseñar estas habilidades a personas en todos los niveles de comprensión y diseñar un plan pragmático para implementar el nuevo VCS (*) en el flujo de trabajo del equipo.

2. Comience un proyecto "skunk-works" para probar y validar el nuevo VCS en un pequeño proyecto paralelo. Elige 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 en el flujo de trabajo de CONCRETO, entonces puedes intentar extenderlo al resto del equipo y tienes un par de evangelistas para ayudarte a hacerlo.

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