Actualizar desde svn sin fusionar automáticamente

Question

Mi compañero de trabajo tiene un problema con la forma en que funciona la actualización de svn, pero no estoy seguro de por qué, por lo que esta pregunta tiene dos caras. Primero, cómo resolver su problema de la manera que él quiere, y segundo, ¿debo tratar de convencerlo de que la forma en que TortoiseSVN hace las cosas ahora es la mejor (y si es así, cómo)?

su pareja ideal de casos de uso

1. derecho click-> SVN actualización
2. SVN tira en los cambios del repositorio, siempre y cuando el archivo no ha cambiado en la copia de trabajo
3. Si tanto el la copia de trabajo y HEAD han cambiado, quiere que se le pregunte antes de que ocurra algo, y hacer la fusión él mismo (incluso si es un escenario donde svn lo resolvería fácilmente).

Supongo que es una solicitud lo suficientemente razonable, pero el hecho de que no quiera confiar en SVN me molesta, aunque en realidad no me afecta ni a mí ni a mi trabajo. No es nuevo en el control de versiones, ya que utilizó CVS, SVN y ClearCase antes. Afirma que pudo hacer esto en svn antes (también, él es muchos años mayor que yo).

Answer 1

¿Quizás pueda convencerlo de que deje svn hacer los cambios, y que los revise antes de registrarse?

El comando 'svn diff --diff-cmd = kdiff3' me parece útil para exactamente este escenario. Aunque es cierto que esto es Linux y su sintaxis variará con TortiseSVN.

Answer 2

TortoiseSVN permite editar un archivo de configuración de Subversion, así que supongo que esta opción se puede configurar allí. Puede acceder a ella a través de Configuración-> General y haciendo clic en "Editar" en el cuadro de grupo subversión, en la línea "Archivo de configuración de Subversion".

En cuanto a la cuestión moral, desde el punto de vista de los puristas, él podría estar en lo cierto, pero parece más trabajo manual y propenso a errores para mí.

Answer 3

Quizás puedas aconsejarle que pruebe git. git proporciona un comando "oculto" para guardar el estado de la copia de trabajo antes de hacer una actualización desde el repositorio.

Citando a partir de la descripción en el manual page:

Uso alijo git cuando desee grabar el estado actual de la directorio de trabajo y el índice, pero quiere volver a un directorio de trabajo limpio .

Answer 4

Solía ​​tener mucho miedo a las fusiones, pero nunca he visto un caso en el que la combinación automática de SVN fallara. Puede arruinar lógicamente la lógica del negocio, ya que dos ediciones lógicamente pueden entrar en conflicto sin conflicto físico, pero no creo que realice una fusión automática a menos que sea apropiado.

Si no tiene pruebas de regresión, su cow-orker puede tener razón debido al hecho de que no hay una revisión de "Logic Merge"; pero si tiene una cobertura de prueba decente, realmente no vale la pena el tiempo.

Realmente me desagrada la "sintaxis de combinación" de SVN para los conflictos, pero la mayoría de las herramientas parecen ocultarlo.

Answer 5

Suponiendo que no puede convencer a su compañero de trabajo a cambiar de opinión, este hilo de correo electrónico podría ser de ayuda para obligar a Subversion que le permita hacer todo manualmente fusión:

http://www.nabble.com/Forcing-conflicts-on-svn-update-to21176148.html#a21176148

Answer 6

creo que la mejor solución aquí podría ser para hacer uso del TortoiseSVN client-side hooks que están disponibles.Puede usar el gancho de Actualización inicial o Actualización previa y, en el script de enlace, comprobar la copia de trabajo local para ver si hay cambios no confirmados y, de ser así, cancelar la actualización.

Answer 7

la educación parece ser la única respuesta verdadera en este caso

Answer 8

TortoiseSVN FAQ: "prevent subversion from doing automatic merges".

edición: estoy copiando la respuesta ligado en el FAQ para proteger esta respuesta de enlace roto:

Algunas personas no les gusta el hecho de que Subversion fusiona los cambios de otros con su propia copia de trabajo local cambia automáticamente en la actualización. A continuación, se indica cómo forzar esos archivos en un estado conflictivo para que pueda combinar manualmente según su conveniencia.

En TortoiseSVN-> Configuración-> Subversion archivo de configuración, haga clic en el botón Editar . Cambie la sección [helpers] añadiendo

diff-cmd = "C:\\false.bat" 
diff3-cmd = "C:\\false.bat" 

(tenga en cuenta la doble barra invertida) Crear el archivo C:\false.bat que contiene dos líneas

@type %9 
@exit 1 

Esto hace efectiva auto-fusión fallan cada vez, forzando el archivo en conflicto.

La razón de la curiosa línea type %9 es que el diff3-cmd envía la salida combinada a stdout. Subversion toma esto y sobrescribe su archivo local con los resultados de la fusión. Agregar esta línea evita obtener un archivo local vacío .

Answer 9

Seleccione el archivo en cuestión en el Explorador de Windows, a continuación, Shift + haga clic derecho sobre el archivo, y bajo TortoiseSVN verá ahora algunas nuevas opciones, entre ellas "Diferenciar con URL" - seleccione la URL del archivo en el repositorio y elija "HEAD revision". Esto mostrará su copia de trabajo actual (que se basa en una revisión sin cabeza) a la izquierda, y la revisión de cabeza a la derecha.

Ahora puede copiar manualmente los cambios de derecha a izquierda (de la cabeza a WC), seleccionando manualmente los cambios que pertenecen y cuáles no. Después de esto, SVN aún piensa que su copia de trabajo se basa en una revisión anterior. Haga una actualización, pero esto no cambiará nada (creo), porque ha realizado todos los cambios manualmente. Entonces cometer como de costumbre.

Obviamente, esto sería extremadamente tedioso de hacer para cada archivo, uno por uno. Pero si se trata de un solo archivo con algunos cambios, entonces esto podría funcionar.Quizás si es lo suficientemente tedioso, la persona cederá y confiará en el algoritmo de fusión incorporado de SVN.

Answer 10

Tan incómodo como su compañero de trabajo es con combinaciones automáticas, me siento incómodo con compañeros de trabajo que no realizan fusiones automáticas. En mi opinión, es la mentalidad equivocada. Cuando no aceptas todos los cambios del repositorio eliges desvincular el código, pero hacerlo de una manera que no incluye se siente como como no comprometido. Es una mentalidad que es propensa a introducir y/o reintroducir errores.

Cuando revisa una combinación antes de permitirla, está pensando en qué cambios va a permitir en su código base, cuando en realidad está decidiendo qué piezas de código comprometido va a eliminar de la código base Es una distinción sutil pero importante.

Por supuesto, los cambios deben reconciliarse y, por supuesto, es posible que deba repasarse o modificarse el código. Si no se aceptan los compromisos de otras personas, uno puede deshacer las confirmaciones sin reconocer que eso es lo que realmente está haciendo.

Answer 11

En realidad, creo que una ligera desconfianza en la fusión puede ser algo saludable. En mi opinión, es un problema con svn que no puede verificar sus cambios como están y luego, una vez que están seguros, combinarlos. Pero se puede hacer de forma manual:

1. Pedido tronco
2. hacer cambios y prueba
3. Branch copia de trabajo a una rama temporal
4. Commit (uf, los cambios son 100% pura y completamente seguro)
5. Cambiar a línea externa
6. rama Reintegración (este es el paso de combinación, pero los cambios son seguros en el ramo)
7. commit
8. rama Borrar

Se añade medidas adicionales para el flujo de trabajo, pero puede simplemente añadir que la paz de la mente. También te da un equivalente cercano de los shelvesets de tfs.