2009-02-26 12 views
5

Soy nuevo en SVN. Después de trabajar en una rama de un día o así, he tratado de combinar los cambios desde el tronco hasta la rama:SVN marca archivos completos como conflictivos

svn merge svn://server/trunk 

El problema es que cada vez SVN encuentra un archivo en conflicto, no es capaz de reconocer la línea de cambios de formación y marca toda la línea como conflictiva. Experimenté con muchos otros clientes SVN y también intenté alternar las opciones de línea final y espacio en blanco sin ningún progreso. ¿Qué estoy haciendo mal? Creo que este es el caso de fusión más simple posible, por lo que espero que funcione con la configuración de Subversion más predeterminada, cualquier cliente y en cualquier versión de SVN. ¿Es alguna captura conocida para principiantes?

Cliente: 1.5.5 (SlikSvn: tag/[email protected]) WIN32

Servidor: 1.4.6 (r28521), Windows

Editar

Basado en las sugerencias en comentarios y respuestas a continuación, hice más investigación:

  1. Los archivos problemáticos son UTF8.

  2. No tienen ninguna propiedad SVN.

  3. El comando "svn diff" identifica correctamente las diferencias.

+0

Windows? Linux? ¿Tortuga? –

+0

Gracias por indicarme eso. Edité la publicación. –

+0

¿Qué tipo de archivo es? ¿Tiene algún conjunto de svn: props? ¿Qué muestra un svn diff si compara su versión de sucursal con la versión troncal? –

Respuesta

5

Tuvimos este problema recientemente y encontramos que era un problema con el uso de un servidor 1.4.x y un cliente 1.5.x. Subversion 1.5 introdujo una fusión más inteligente, pero necesita que el servidor y el cliente ejecuten 1.5 para aprovechar esto.

Encontramos que especificar el rango de números de revisión que queríamos fusionar dio los resultados esperados.

0

¿Has probado a usar TortoiseSVN? Viene incluido con ToroiseMerge, que me parece una fusión decente también.

+0

Lo he intentado, pero con el mismo resultado. También me desconcertó la interfaz y opté por el mínimo común denominador: un cliente de línea de comando. Lo intentaré una vez más y proporcionaré una actualización. –

0

No he usado SVN a ton, y solo lo he usado a través del complemento eclipse, pero puede haber algunos escenarios en los que simplemente debe indicar qué caso utilizar (su archivo local frente al remoto) fusionar un conjunto de cambios disjuntos salientes y entrantes no suele ser un problema, pero si una línea entra en conflicto con ciertos tipos de cambios (en eclipse marca toda la línea/bloque como roja) puede que solo necesite aceptar una u otra, ya que probablemente no se fusionará más por sí mismo.

0

Compruebe la propiedad svn: mime-type en sus archivos. Si existe un conjunto de propiedades así y su valor no comienza con 'text /', entonces Subversion trata esos archivos como binarios y no como texto.

Si sus archivos están codificados en utf-16, Subversion también tratará esos archivos como binarios por defecto.

+0

Los archivos problemáticos no tienen propiedades SVN, pero parecen estar en UTF8. ¿Cuenta? –

+0

utf8 no es problema. – Stefan

2

He seleccionado la respuesta de Mark. Esto es solo para resumir y proporcionar más detalles. Mi problema es causado por el hecho de que estamos usando SVN 1.4 que no es compatible con las funciones de fusión 1.5 más avanzadas.Según lo indicado por la respuesta seleccionada, descubrí que tengo que usar el siguiente formato del SVN comando de combinación (en caso de que quiera propagar los cambios desde el tronco a mi sucursal):

svn merge svn://dpr/branches/[email protected] svn://dpr/[email protected] 

supongo que mi confusión era causado por el hecho de que el libro de SVN y los clientes que estaba usando estaban asumiendo silenciosamente que ya estaba ejecutando 1.5 y los ejemplos y los métodos de fusión predeterminados estaban usando las nuevas características. Para ser justos, la introducción a la sección de Fusión básica en los libros de SVN lo menciona (que noté solo cuando resolví el problema).

+0

¡El libro de SVN también causó confusión en nuestro caso! – Mark

Cuestiones relacionadas