2010-02-05 17 views
22

Soy bastante nuevo en Subversion y Subclipse y veo algunos problemas que me llevan a pensar que hay una diferencia entre la actualización a la cabecera y la sincronización. Específicamente, me parece que cuando trato de revertir (utilizando el historial de subclipse), a menudo recibo un mensaje que dice "No se puede revertir la fusión de un rango desde el historial futuro de una ruta, intente actualizar primero". Mi sincronización debería garantizar que tengo la versión 'principal' de todos los archivos de mi sucursal en el REPO, pero hacer una "Actualización para encabezar" soluciona el problema ... ¿qué ocurre? Intenté comprobar la consola de SVN para ver qué está cambiando, pero no es muy detallado.SVN Sincronizar vs Actualizar a Head (subclipse)

Ideas?

Tengo una segunda pregunta, pero supongo que la respuesta a la primera arrojará luz sobre ella. Si tiene curiosidad y tiene tiempo para leer, también lo escribiré. Aquí está el escenario ... He ramificado todos mis archivos desde una etiqueta de "Producción", y he comenzado a trabajar en mi proyecto. Después de algunos commits, verifico el historial de un archivo modificado y noto que la versión 'en negrita' (de acuerdo con la documentación, esto debería ser la cabeza) está debajo de todos mis commits. Es como si lo que tengo no fuera cabeza. Pero head es solo la última versión del proyecto ¿verdad? Entonces, ¿qué me estoy perdiendo?

Gracias por su respuesta y tómese el tiempo para leer esto!

Respuesta

2

Creo que su suposición de que la sincronización es la misma que la actualización a HEAD es falsa. Si, en el lenguaje de Subclipse, "sincronizar" significa "confirmar", entonces es ciertamente falso porque la confirmación no actualiza su copia de trabajo. Tienes que actualizar explícitamente después de que te comprometas a estar en HEAD.

Lo que me lleva a su segunda pregunta: Creo que el motivo por el que la línea en negrita está por debajo de otras confirmaciones es por la razón anterior — que confirma que no se actualiza. Esto significa que puede enviar un cambio a un archivo, y luego mirar otro archivo y ver que es más antiguo que HEAD, porque esos otros archivos tampoco se han llevado a HEAD.

Este artículo puede ayudar a aclarar este concepto de las revisiones mixtas: http://markphip.blogspot.com/2006/12/mixed-revision-working-copies.html

También animo a familiarizarse con el SVN documentation, como trabajar con plugins y extensiones para la subversión siempre se hace más fácil cuando usted entiende cómo el SVN subyacente el sistema funciona

+0

Hey Mike, Me tomó un vistazo a ese artículo, pero no estoy muy seguro de que se aplica. Aunque una confirmación no actualiza tu copia de trabajo, una sincronización debería. Veo no solo cambios salientes sino entrantes. ¿No sería eso lo mismo que actualizar? – gergesi

+1

¡Ahh, la respuesta está en ese artículo pero en la sección sobre carpetas! Cuando confirmo un archivo, su carpeta principal no se mueve a mi revisión. Sabe sobre la revisión (está presente en la historia) pero no se mueve hacia arriba. La sincronización ignora esto, pero una actualización de HEAD lo resuelve. – gergesi

26

Hay una diferencia. Cuando utiliza la vista Sincronizar, solo se actualizan los elementos en la vista. Con Subversion, las carpetas también tienen una revisión que se ejecuta cada vez que se modifica un elemento secundario. Sin embargo, dado que estos no aparecen en la vista, nunca se actualizan. Cuando haces Team> Update en el proyecto, todas las carpetas y archivos se actualizan en una sola revisión uniforme. Tengo un par de entradas de blog que explican esto:

Ésta explica el SVN concepto básico de una copia de trabajo mezclada, y es esencial para entender esto:

http://markphip.blogspot.com/2006/12/mixed-revision-working-copies.html

El segundo muestra una característica en Subclipse para hacer frente a esto:

http://markphip.blogspot.com/2006/12/subclipse-synchronize-feature-show-out.html

Desde el segundo blog fue escrito, la mayoría de los usuarios Subclipse encontró que no les gustaba esta función a pesar de que él lps con este problema Por lo tanto, ahora está desactivado por defecto en las versiones actuales. No creo que nadie lo use nunca más.

Lo principal es utilizar ocasionalmente Team> Update en su proyecto para llevarlo todo a una sola revisión uniforme.

Marcos

+0

¡Gracias @Mark! Esta y las publicaciones de tu blog vinculadas definitivamente me ayudaron a aclarar algunas cosas sobre SVN y Subclipse. –

Cuestiones relacionadas