Las palabras key de revisión PREV, BASE o COMMITTED no son válidas para URL mientras se reintegra una twig

He ramificado mi troncal (en una revisión anterior) e implementado / comprometido una nueva característica e implementado parte de otra característica localmente en la sucursal. Ahora necesito reintegrar la function terminada al maletero.

I svn cp branches/completedfeature branches/uncompletedfeature para get la característica parcialmente completa en su propia twig. Entonces, svn revert -R . todo en la primera twig para que esté actualizado.

Ahora cuando me svn merge --reintegrate ../../branches/completedfeature del tronco, me sale este error críptico (a mí):

 PREV, BASE, or COMMITTED revision keywords are invalid for URL while reintegrating a branch 

Tanto el tronco como la twig de características completadas están actualizadas sin cambios locales. Que esta pasando?

Tuve este error.

Su pregunta fue casi el único resultado de google ( aquí hay una descripción de las palabras key ).

Tenía una twig larga con otras twigs fusionadas en ella … el process de parche iba a ser largo y difícil. Así que a pesar de que esta sección de SVN networkingbood sugiere que debe unir dos copys de trabajo, intenté de manera optimista reintegrarme desde la URL y ¡funcionó!

 cd myLocalTrunk svn merge --reintegrate https://svn.blah.blah/blah/blah/branches/myBranch svn ci -m "reintegrating myBranch into trunk" 

Parece que lo ramifiqué mal / mal. No he descubierto cómo solucionar esto de la manera correcta, para cualquiera que se encuentre en esta situación aquí es cómo obtuve mis cambios en el baúl preservando la mayor parte de la historia de esta twig efímera:

Encuentra todos tus files que cambiaron diff -ur trunk branch . Asegúrate de mirar a través de los diff ya que cualquier cambio en el trunk que no esté en la twig se revertirá, así que ignora esos files o si hay cambios en un file en ambos treees, asegúrate de editar el diff manualmente más tarde.

Copie los files nuevos con svn para conservar su historial svn cp branch/path/file trunk/path/file

Ahora solo necesita los cambios en los files que no cambiaron. No se puede hacer una fusión de dos fonts porque (al less en svn 1.7 en cygwin) se eliminará y luego se agregará el file, borrando el historial. La opción que elegí fue build / aplicar un parche y hacer un post de compromiso sobre lo que sucedió.

Hay muchos mejores lugares para aprender a aplicar parches, pero a continuación se muestra lo que hice. Tenga en count que tendrá que corregir manualmente sus problemas de fusión si tiene files que se cambiaron en ambos treees.

Construya su parche con diff -u trunk/path/file branch/path/file >> patch.patch Haga esto para cada file, o pase de nuevo en el indicador recursivo y haga el trabajo difícil.

Haga una ejecución en seco para asegurarse de que el parche funcione y obtenga los parches correctos parche patch -p0 --dry-run < patch.patch Luego, patch -p0 < patch.patch

Luego, asegúrese de que el proyecto se compile y verifique.

Dejando abierta esta pregunta con la esperanza de que alguien sepa la respuesta real.

En general, no hay necesidad de utilizar files de parche aquí; cualquier range "-cx" o "-rx: y" es en realidad un set de cambios, es decir, un tipo de parche que se puede aplicar. Hagamos un ejemplo completo, así que inicialmente

 svn copy trunk/path/file branch/path/file 

y después de eso uno puede trabajar en el maletero. Ahora necesita conocer el range de revisión para aplicar los cambios al objective, dado que el número de revisión es global, puede solicitar ambos files, por ejemplo

 svn info trunk/path/file # 35 svn info branch/path/file # 27 

Este es el range para usar, ahora puedes decir

 svn merge -r 27:35 trunk/path/file branch/path/file 

Puede pensar que está creando un file de parche internamente para el range 27:35 que se aplica al destino. Siempre que esto sea solo file a file, ni siquiera puede get un conflicto de tree (piense en los files renombrados en una fusión de directory).