Subversion marca archivos no modificados como modificados

Question

Aquí hay un problema extraño que encontré al usar Subversion: al fusionar desde una rama de desarrollo a trunk (o viceversa, para el caso) Subversion marcaría muchos archivos como cambiados, mientras no tenían cambios .

Esto es lo que sucede:

1. En mi rama encomiendo 1 archivo modificado
2. En el tronco que se funden en que se comprometan
3. Mucha otros archivos y directorios están marcados como 'modificado' sin en realidad haber sido cambiado (ni siquiera el espacio en blanco, terminaciones de línea, propiedades o ese tipo de cosas).

Técnicamente, cometer estos cambios sin cambios no haría ninguna diferencia, pero no quiero agregar ruido a mis registros.

¿Alguna idea de qué podría causar esta molestia y cómo prevenirla? ¿Puedo preguntar a Subversion por qué se ha marcado un archivo como modificado, para saber si era el contenido, las propiedades, etc. del archivo?

FYI: cliente de subversión en el rango 1.6.x, servidor en el rango 1.5.x. Usando una combinación de Versions.app y la CLI en Mac OS X Leopard.

Answer 1

Lo que sucede es que una vez que un archivo/carpeta tiene mergeinfo explícito (es decir, una propiedad svn:mergeinfo), cada combinación posterior a la rama actualizará ese mergeinfo incluso si el archivo/carpeta no está relacionado. Esto es realmente molesto ya que introduce más y más desorden en la lista de cambios para cada combinación.

Para evitar esto, solo combine en la carpeta "raíz" de la rama, por ejemplo "/branches/maintenance2.x". Ninguno de los archivos o carpetas debajo de "/branches/maintenance2.x" debería obtener mergeinfo.Siga el merging advice in the svn book.

Desafortunadamente, incluso si se fusiona solo en la carpeta "raíz" de la rama, aún pueden aparecer propiedades svn:mergeinfo vacías en archivos y carpetas individuales cuando se copian, para indicar que no han recibido las mismas fusiones que sus hermanos .

Si se fusiona solo en la raíz, entonces probablemente sea seguro eliminar el superfluo subárbol mergeinfo. Una forma de hacerlo es haciendo una eliminación recursiva de la propiedad svn:mergeinfo en cada archivo y carpeta en la raíz del proyecto.

---

Parece que se ha corregido en SVN 1.7. De las notas de la versión: Reduced subtree mergeinfo changes.

Answer 2

Podría ser algún tipo de cambio de propiedad, posiblemente una modificación automática del atributo svn: mergeinfo. Puede ver si se trata de una modificación de propiedad ejecutando "svn stat". Si la "M" está en la primera columna, se trata de cambios en el contenido, si está en la segunda columna, su propiedad cambia.

Answer 3

El cambio está en las propiedades del archivo. Si ejecuta svn proplist, verá muchas entradas de mergeinfo. Esto se debe a que svn rastrea las fusiones en las propiedades del archivo. Esta es una nueva característica de 1.5, por lo que no ocurrió en versiones anteriores.

Nunca he entendido por completo la razón exacta de por qué sucede esto, pero tiene que ver con la implementación interna que se filtró. Tratar de entenderlo sin entender cómo se implementa svn es, hasta donde he llegado a la conclusión, imposible. Sin embargo, generalmente la causa raíz tiene que ver con las combinaciones de subárboles. P.ej. Si fusiona los cambios de un subdirectorio o un único archivo, en lugar de la rama/etiqueta completa. Para rastrear lo que se ha fusionado, subversion colocará la propiedad mergeinfo en el nodo más general, pero aparentemente no es lo suficientemente inteligente como para elegirla. Puede solucionar el problema editando manualmente mergeinfo. Simplemente elimine la propiedad de todos los nodos debajo del tronco y asegúrese de que el tronco tenga todas las revisiones fusionadas en su mergeinfo. Por supuesto, esto significa que debe asegurarse de que los cambios se hayan fusionado realmente.

En general bastante confuso, pero la buena noticia es que los desarrolladores svn en realidad son trabajando para que todo sea más sencillo.