resolviendo conflictos binarios svn

Question

Utilizo svn para un proyecto en el que estoy trabajando con otros desarrolladores. Svn funciona bien para el control de código fuente, sin embargo, todos somos conflictos cuando cometemos los dlls.

Cuando lo hago, resuelvo el conflicto (que elimina mis dlls ya que el programa diff no puede manejar archivos binarios) y luego tengo que reconstruir para confirmar. ¿Cómo se pretende resolver conflictos como este?

Editar:

Los dlls están en una carpeta svn separada ya que el proyecto es un mod de juego y los no programadores necesitan acceso a las últimas compilaciones.

Answer 1

Como se menciona en otras respuestas aquí: en primer lugar, no debe versionar sus dlls generados. Pero si realmente tiene para versionarlos, entonces puede resolver un conflicto sin usar una herramienta de diferencias que elimine sus archivos dll:

Por cada archivo en conflicto, Subversion coloca tres archivos no versionados adicionales en su copia de trabajo:

filename.mine

Este es su archivo tal como existía en su copia de trabajo antes de actualizar su copia de trabajo, es decir, sin marcadores de conflicto. Este archivo solo tiene sus últimos cambios. (Si Subversion considera que el archivo no se puede fusionar, el archivo .mine no se crea, ya que sería idéntico al archivo de trabajo).

filename.rOLDREV

Este es el archivo que era la revisión BASE antes de actualizar su copia de trabajo. Es decir, el archivo que retiró antes de realizar sus últimas ediciones.

filename.rNEWREV

Este es el archivo que su cliente Subversion acaba de recibir del servidor cuando actualizó su copia de trabajo. Este archivo corresponde a la revisión HEAD del repositorio.

Aquí OLDREV es el número de revisión del archivo en su directorio .svn, y NEWREV es el número de revisión del repositorio HEAD.

Ahora, para resolver dicho conflicto, elimine los archivos adicionales que no desea:

• si desea mantener su propio dll, elimine los archivos filename.rOLDREV, filename.rNEWREV
• si desea mantener el dll del repositorio, elimine los archivos filename.rOLDREV y filename.mine, luego copie filename.rNEWREV al nombre de archivo

después de eso, ejecuta

svn resolved filename

para decirle a Subversion que resolvió el conflicto usted mismo.

Answer 2

Si es un archivo DLL que está CONSTRUYENDO (en lugar de uno externo para el que no tiene fuente), entonces la fuente debe estar en control de fuente, no el binario.

Si no desea incluirlo en ese repositorio particular, puede incluirlo como un svn: externo.

Answer 3

Generalmente, no almacenaría sus propias DLL compiladas en el control de código fuente. ¿Tiene una razón específica por la que necesita hacer esto?

Configuré mis entornos de desarrollo para que cualquiera pueda construir cualquiera de los componentes de mi proyecto independientemente de cualquier otra persona. De esta manera, lo único que está en mi sistema de control de fuente es mi código fuente . Esto tiene una serie de beneficios:

• Evita conflictos de archivos binarios al intentar registrar archivos DLL o EXE
• El volumen de datos rastreados por su sistema de control de fuente es mucho más pequeño, lo que lo hace más rápido
• Cuando los desarrolladores siempre crean sus propios archivos DLL, pueden estar razonablemente seguros de que el código fuente que tienen coincide con el archivo compilado. Si está utilizando algo que alguien más construyó, entonces nunca puede estar seguro.

Como se menciona en los comentarios, puede ser perfectamente razonable almacenar archivos DLL de terceros en su sistema de control de código fuente, particularmente si en realidad no tiene el código fuente para ellos. También trabajé en proyectos donde almacenamos archivos de distribución ( .tar.gz , etc.) para varias bibliotecas de código abierto en el control de código fuente, luego tuve un sistema completo de Makefile s que construyeron esas bibliotecas como parte de un objetivo de construir todo.

Answer 4

Para archivos binarios, la mayoría de las veces, desea aceptar cualquiera de las versiones. Por ejemplo, si el archivo en cuestión es una herramienta ejecutable, por lo general, una versión puede ser más nueva que la otra, y esa puede ser la que desea utilizar.

Para aceptar la versión que está en la rama de la que se está fusionando, use:

svn resolve --accept=theirs-full path/to/filename

Para aceptar la versión que estaba anteriormente en la rama actual, use:

svn resolve --accept=mine-full path/to/filename

A veces, SVN se negará a usar theirs-full con una advertencia:

svn: advertencia: W195024: opción de resolución de conflicto no aplicable dada para la ruta en conflicto

porque SVN es una mierda cuando se trata de fusionar. En ese caso, debe copiar los archivos manualmente como en la respuesta aceptada https://stackoverflow.com/a/410767/2279059, en lugar de utilizar las opciones de línea de comandos que están destinadas a lo que está intentando hacer. Si sabe que ambos archivos son idénticos (pero SVN todavía los marca como conflictivos por los motivos ya mencionados), también puede usar

svn resolve --accept=working path/to/filename

Si bien esto, en el caso de archivos idénticos, es efectivamente el mismo que todos los demás comandos, SVN no se negará cobardemente a ejecutarlo. ¿Esto tiene sentido? No lo hace Tratar con eso.

Answer 5

Es razonable tener también binarios en el control de versiones:

• Evita la molestia de reconstruir para las personas que solo usan el binario.

• El binario se clava cuando lo liberas.

Para que esto funcione, el binario debe corresponder siempre a las fuentes. Entonces, si ha combinado fuentes, necesita reconstruir el binario a partir de ellas, elegir uno de los binarios de las versiones fusionadas no funcionará.

Answer 6

Asegúrese de que sus dlls tengan la propiedad svn: mime-type establecida en application / octet-stream o algún otro tipo que no sea de texto.

svn propget *.dll
svn propset svn:mime-type application/octet-stream *.dll

Todavía tendrá que resolver los conflictos cuando ocurran.

Y verifique el Tipo de contenido del archivo capítulo de la documentación.

Answer 7

Entonces, si tiene los * .dlls en una carpeta separada, es mucho más fácil hacer lo siguiente:

1. Directamente antes de compilar su cambio, actualice su carpeta * .dll mejor también actualice sus fuentes, si confía, que sus colegas solo confirman el código fuente compilable. (en caso de conflicto (cuál sería su culpa en ese momento, ya que cambió algo antes de actualizar a la última revisión))
2. Haz tu construcción.
3. Cometer directamente el resultado.

Alternativamente:

no compile en la ruta del directorio, compile en algún lugar externo, hasta que esté satisfecho con lo que sea el resultado.

Luego proceda de la siguiente manera:

1. Actualice su copia de trabajo de la carpeta dlls (si hay algún conflicto es su culpa y resuelva el conflicto " mantenga la suya ")
2. Copie sus archivos .dlls de trabajo en la copia de trabajo
3. Informe a sus colegas que enviará una nueva revisión (puede dejar que esto desaparezca)
4. Compromete tu trabajo si hay algún conflicto, debería ser su culpa.

Ahora tiene dos posibilidades:

5a. Eres una persona muy detestable y resuelves el problema manteniendo el mío.

5b. Trabaja como debe trabajar ... Lea el archivo de registro y descubra quién también se comprometió durante el poco tiempo que necesitaba para copiar su trabajo en la carpeta y presionó confirmar. Habla con ese colega. Acordar un curso de acción adicional.