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

13

En el trabajo usamos SVN, pero solo en nombre. No nos ramificamos ni fusionamos. Mantenemos dos copias del repositorio, una sirve como la rama "etiqueta" que se copia cuando hacemos una implementación y nos guardamos para corregir errores y el tipo de características inmediatas de "esto tiene que ponerse en funcionamiento lo antes posible". Debemos recordar copiar los cambios realizados en una copia a la otra copia (el "troncal"). 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 poder cometer. 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 introducción de Mercurial al resto del equipo como una "mejor manera" de hacer las cosas porque la bifurcación es instantánea, la fusión es mucho más fácil, y podemos comprometer las cosas localmente al contenido de nuestro corazón y solo empujarlas a la central. Rama cuando estén listos. Obtendríamos todos los beneficios de SVN (y no estamos obteniendo muchos beneficios ahora mismo de todos modos ya que nadie realmente entiende SVN) además de las nuevas funciones, no tenemos que tener toneladas de archivos no versionados flotando alrededor, 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, y que "Pull" es como la Actualización de SVN (lo que el equipo denomina "get latest").

¿Es este un buen enfoque para tomar? Tenga en cuenta que el equipo es muy flexible y estará de acuerdo con cualquier cosa que mejorará nuestra calidad de trabajo y hará que las cosas sean más fáciles. El CIO incluso me preguntó cuando mencioné que no estábamos usando SVN a su potencial "Es ¿Hay algo mejor que podamos usar? así que él también está a bordo.

    
pregunta Wayne Molina 21.12.2011 - 13:29

6 respuestas

15

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.

    
respondido por el Ed James 21.12.2011 - 15:47
21

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.

    
respondido por el BlackICE 21.12.2011 - 15:54
10

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).

    
respondido por el alex 21.12.2011 - 14:57
5

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. ...

    
respondido por el Brian Knoblauch 21.12.2011 - 15:04
3

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)

    
respondido por el Lazy Badger 21.12.2011 - 15:43
2

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).

    
respondido por el Angelo 21.12.2011 - 16:55

Lea otras preguntas en las etiquetas