¿Cómo evito las fusiones complicadas en Subversion?

Soy nuevo en Subversion (SVN) proveniente de un background Visual Source Safe (VSS). En VSS, la persona que edita un file comtesting el file y bloquea a los demás usuarios para que no lo editen a través de Visual Studio. Entiendo que SVN es un model concurrente que permite que varias personas trabajen en el mismo file y luego fusionen los cambios. Mi pregunta es esta:

  1. ¿Cuál es el mejor enfoque para evitar que los usuarios editen el mismo file (escribir toneladas y toneladas de código) y enfrentar una fusión complicada para sus cambios o, peor aún, escribir una tonelada de código solo para descubrir que el file está bloqueado por otro usuario?

  2. ¿Hay alguna manera de notificar a un usuario cuando recupera un file que está siendo editado por otro usuario o actualmente está bloqueado por otro usuario?

Otros detalles:

Usando el Servidor VisualSVN como Servidor SVN.
Uso de clientes de TortoiseSVN y AnkhSVN.

También soy un usuario anterior de Visual Source Safe. Las fusiones solían volverme loco hasta que me di count de que no es un problema tecnológico, sino un problema para las personas. Al usar VSS, la mayoría de los desarrolladores intentan hacer todo el trabajo posible antes de tener que verificar el código. Este comportamiento es lo que contribuyó a las fusiones complicadas.

Aquí hay algunas cosas para mitigar esto:

  • Siempre actualice su copy de trabajo antes de comenzar
  • Verifique a menudo. Esto hará que el código cambie más pequeño, lo que será más fácil de combinar automáticamente
  • No deje el código de trabajo sin marcar
  • Los desarrolladores deben crear su propia twig, si los cambios tomarán varios días o más

Esas cosas ayudaron inmensamente, especialmente a medida que los equipos en los que trabajaba se hicieron cada vez más grandes. Replicar el comportamiento de locking de VSS es una muy mala idea y causará más problemas. Simplemente adopte el nuevo flujo de trabajo.

Si aún desea utilizar una herramienta, le sugiero que consulte SVNMonitor .

Me gustaría sugerir un enfoque diferente para usar la subversión.

  • Deberías recibir actualizaciones con frecuencia.
  • También debe registrarse temprano y con frecuencia.

Con este enfoque, la fusión generalmente no es frecuente y ocurre automáticamente. En el caso de conflictos, estos son a menudo más pequeños.

Un par de puntos que encontré en un lugar anterior donde pasamos de un sistema basado en locking a SVN.

No es realmente una buena idea tratar de replicar el comportamiento lock-edit-unlock en SVN ya que ha sido diseñado de tal manera que no necesita trabajar de esa manera. Los algorithms de combinación utilizados por SVN son bastante buenos y solo he encontrado algunas ocurrencias en las que se requirió la intervención manual durante una fusión. Es sorprendentemente raro que dos personas que trabajan en el mismo file toquen realmente la (s) misma (s) línea (s) y esta última suele ser la única vez que se necesita una intervención manual.

SVN está realmente diseñado para ser utilizado en un entorno donde a menudo se actualiza desde el troncal o su twig actual. Si tiene que hacer un trabajo o trabajo a más largo ploop que cambie una gran cantidad de código en un file, es mejor que utilice una sucursal para hacer el trabajo y combinarlo. Sí, tendrá que pasar por alguna fusión dolor de vez en cuando pero es considerablemente less doloroso de lo que se obtiene con un sistema que no fue diseñado para funcionar de esa manera.

Si intentas usar SVN no como 'SVN nativo' sino como VSS con un nombre diferente, será doloroso y no valdrá la pena. Póngase cómodo con el nuevo paradigma y se sorprenderá de lo agradable que es trabajar de esa manera en comparación con el viejo "solo un usuario edita un file determinado en cualquier momento dado".

En primer lugar, probablemente sea conveniente evitar escribir "toneladas y toneladas de código" sin verificar los files, si es posible. Si tiene un buen set de testings unitarias (y si no, ¿por qué no? :), entonces, mientras se registre en la barra verde, las confirmaciones frecuentes son las mejores.

Entonces, si tiene cambios que llevan mucho time por necesidad, vale la pena hacer una svn update periódicamente para mantenerse sincronizado con la troncal lo más cerca posible. Subversion es bastante respetable en la fusión (en comparación con VSS) y manejará bien la mayoría de las cosas.

Cualquier cosa que no pueda manejar, entrará en un estado de conflicto, dejándolo resolver los conflictos con una herramienta de combinación de su elección (recomiendo WinMerge para esto, es un as).

La única ocasión en que puede querer usar el viejo model de locking de estilo VSS es con los files binarys (documentos MS-Word, etc.) que desea versión, pero ese SVN no puede fusionar automáticamente los cambios de múltiples fonts.

No es un problema. Usando Tortoise SVN, haz esto …

  1. En el Explorador de Windows, haga clic con el button derecho en el (los) file (s).
  2. Elija "Tortoise SVN" y luego "Get Lock …"
  3. En el cuadro de dialog Bloquear files, complete el motivo del locking.
  4. Haga clic en Aceptar.

Aunque SVN tiene un command de locking , la forma más común de usar SVN implica el enfoque optimista para el locking.

Eso significa que usted y yo podemos editar el mismo file y no nos preocupamos demasiado (la mayoría de las veces no lo hacemos porque estaríamos trabajando en diferentes partes de nuestro proyecto). Si soy el primero en realizar cambios en el file, su bash de confirmación fallará. Es entonces cuando SVN te notificará.

Luego deberá ejecutar el command "Actualizar", que (muy probablemente) fusionará automáticamente mis cambios comprometidos con los cambios locales y luego se realizará su próximo bash de confirmación.

Para evitar meterse en problemas con este enfoque optimista: como otros sugirieron, ¡comprométase a menudo y no comprometa demasiado a la vez!

SVN es un model simultáneo que permite que varias personas trabajen en el mismo file y luego fusionen los cambios.

Creo que se trata más de trabajar en el mismo proyecto que consiste en un montón de files independientes más o less. Trabajar en el mismo file y fusionar los resultados es ciertamente posible , y sucede de vez en cuando, pero definitivamente no es el modo de operación pnetworkingeterminado / deseado. Asi que:

  • Actualiza a menudo.
  • Comprometerse a menudo
  • Evite classs / files grandes (1000 líneas es demasiado). Esto también tiene beneficios adicionales 🙂

Me tomaría un time aprender sobre el "baile de input"

Aquí hay una moneda de diez centavos .

También hay varios artículos en la web sobre esto y cómo aliviar el dolor.

Respuesta corta:

  1. Actualiza a menudo. Checkin temprano, registrándose a menudo. Si trabajas en algo por más time (más de uno o dos días), considera crear una twig de características.
  2. No.

Respuesta algo más larga:

Si más de un desarrollador realiza "toneladas y toneladas de cambios" en el mismo file, algo no está a la altura de la forma en que trabajan sus desarrolladores o con la forma en que las características se distribuyen en diferentes files. He estado trabajando con CVS y SVN en equipos de diferentes tamaños e IME. Hay muy pocos casos en los que la fusión se convierta en un problema real. (Por lo general, se trata de cambios en los services fundamentales, como cadena de caracteres, logging, event handling errores, etc., que requieren cambiar casi todo el código. Tales casos requieren cierta interacción y planificación humana para funcionar sin problemas).

Estoy de acuerdo con todos los demás, en la medida de lo posible check-in temprano y con frecuencia (no siempre es posible). Si está haciendo algo complejo y nuevo, puede hacerlo en una sucursal: se aplica la misma regla, comprométase temprano y con frecuencia, y donde mantenga su sucursal actualizada como sea posible con el código del jefe.

En nuestra experiencia, la mayoría de las personas tienden a no trabajar en el mismo file o al less en la misma parte del file al mismo time (en VSS no podría hacerlo, por lo que sus patrones de trabajo probablemente ya lo respalden en esto).

Una cosa más key: asegúrese de que todos estén usando las mismas reglas para el uso de tabs / espaciado, para el layout y el formateo, esta es una buena práctica, pero cuanto más consistente sea, less probabilidades tendrá de encontrar "diferencias" entre códigos files que realmente no existen

Además, le recomiendo que considere la continuous integration, es decir, tener un server de compilation, esto proporciona beneficios considerables en términos de confianza de que su código comprometido se buildá en un entorno "limpio" y, si está adecuadamente equipado con testings, le dará mayor confianza de que todavía funciona, incluso después de un process complejo de fusión.

Utilizamos TeamCity que hemos encontrado excelente, pero hay otros.