tortoise subir son que proyecto informatica create branches svn

svn - subir - tortoise merge



Subversion fusionando cambios desde un repositorio diferente (3)

Acabo de intentar un breve experimento con TortoiseSVN:

Creando los repositorios de prueba

  1. crear dos nuevos repositorios en rep1 y rep2
  2. echa un vistazo a rep1 en co1
  3. agregue un archivo de texto a co1 y verifíquelo
  4. exportar rep1 a ex1
  5. importa ex1 en rep2

En esta etapa, se encontrará en el estado de haber creado su ''sucursal'' local en un nuevo repositorio. Los dos últimos pasos son todo lo que necesita para un proyecto existente.

Para simular algunos cambios en el repositorio original, modifique el archivo de texto en co1 y confirme los cambios.

Fusionando Cambios

Ahora, para crear su propia copia de trabajo, revise rep2 en co2.

Deberíamos estar preparados para intentar fusionar de rep1 a co2.

Abra el cuadro de diálogo de fusión para co2 y apúntelo en rep1.

Para la revisión ''desde'', seleccione la revisión en la que exportó su copia (en este caso, revisión 1), o la revisión a la cual actualizó por última vez su copia local.

Para la revisión ''a'', seleccione HEAD o la última actualización que desee aplicar.

Resultados

Esto parece funcionar como se esperaba, con las modificaciones de rep1 aplicadas a la copia de trabajo de rep2 en co2. Estos deben ser devueltos a su repositorio local.

Estoy realmente confundido. Quiero hacer algo que a) parece que debería ser bastante simple, yb) otras personas deben hacer todo el tiempo, pero no puedo encontrar la mejor manera de hacerlo en cualquier lugar.

Hay un repositorio externo que contiene un código de terceros. Quiero tomar una copia de la versión 1 del código y ponerla en mi propio repositorio, y luego personalizarla para mis propias necesidades. Cuando se publique la versión 2 de ese código, deseo poder actualizar mi versión personalizada con todos los cambios de la versión 2, conservando mis personalizaciones.

He leído sobre las sucursales de proveedores ( http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html ) pero no entiendo por qué fusionar la copia anterior del código de proveedor y la nueva la copia del código del proveedor debe ser tan complicada (es decir, svn_load_dirs.pl). Seguramente, si el código de terceros está almacenado en un repositorio SVN, se conoce todo el historial con respecto a qué archivos se movieron / se eliminaron, entonces, ¿por qué necesita decirle qué se ha cambiado manualmente?

Citar:

Por ejemplo, tendrá la oportunidad de decirle al script que usted sabe que el archivo math.c en la versión 1.0 de libcomplex se renombró a arithmetic.c en libcomplex 1.1.

También leí ( http://svn.haxx.se/users/archive-2006-04/0285.shtml ) que es posible simplemente ejecutar una fusión entre diferentes repositorios, pero no pensé que eso fuera posible. , y cada vez que lo he probado ha fallado (aunque podría haber estado haciendo algo mal).

¿Alguien puede aclararme esto y sugerir la mejor solución?


El enlace de las sucursales del proveedor que usted proporcionó describe eficazmente el proceso de lo que desea hacer. Es una solución perfecta para permitirle hacer una actualización directa (importación) de la sucursal del proveedor, y luego, como usted alude, le permitirá fusionar las actualizaciones del proveedor con sus cambios en la rama de desarrollo principal.

El problema es que Subversion realmente no proporciona soporte directo para el cambio de nombre de archivos y movimientos de archivos entre directorios para la actualización sucesiva del código del proveedor porque solo se obtienen instantáneas del contenido de los archivos fuente ... algo necesita para ejecutarse. comandos en el sistema de versión para indicar qué cambios se están realizando en el árbol de nombres de archivos que componen la nueva versión. Este es el propósito del proceso de script svn_load_dirs.pl. Te ayuda a manipular tu historial de versiones para que coincida con las ramas para que luego puedas continuar con la fusión. Si el proveedor no cambió el nombre y / o movió archivos entre las versiones que importó, no tendría este problema.

En cualquier caso, el proceso descrito allí es lo que debes / necesitas hacer.


No he intentado esto con un repositorio múltiple, pero no veo por qué no puedes usar las sugerencias de tu segundo enlace.

svn fusionar ORIGINAL @ REV UPGRADE @ REV LOCAL_PATH

Esto efectivamente le dice a SVN que tome todos los cambios entre el pago original y la versión que desea, y que los aplique a su copia local.

Protip: siempre utilizo revisiones explícitas e incluyo el comando de fusión con el mensaje de confirmación, para que pueda revisar fácilmente el historial y comprender cómo reproducir o deshacer cambios.