Mientras que de alguna manera versado en la VCS regular (svn, git y git-svn usuario) me parece que no puede envolver mi cabeza alrededor de este peculiar SVN comportamiento.

Cada vez que necesito para cambiar el nombre de un directorio en mi SVN copia de trabajo de un estado «limpio» – i.e svn status no devuelve nada y todas las otras modificaciones han sido añadidos como así (que es lo que el svn doc sugiere):

svn mv foo bar
svn commit

SVN se queja en voz alta:

Adding         bar
Adding         bar/toto
Deleting       foo
svn: Commit failed (details follow):
svn: Item '/test/foo' is out of date

Como usted desee:

svn update

Que da:

   C foo
At revision 46.
Summary of conflicts:
  Tree conflicts: 1

Hay un árbol de conflicto, mientras que ninguna de terceros a cambio sucedió. Obviamente, la única manera de salir de este árbol conflicto lío es genéricamente (desde el svn libro rojo):

svn resolve --accept working -R .
svn commit

El cambio de nombre de forma remota en la repo, a continuación, actualizar mi copia de trabajo parece bastante braindead:

url=$(svn info | grep -e '^URL:' | sed 's/^URL: //') svn mv $url/foo $url/bar
svn update

Hay una sanción, manera más eficaz para cambiar el nombre de una carpeta que me estoy perdiendo? ¿Cuál es la causa de que particularmente sorprendente árbol estado de conflicto?

  • Puedes publicar el árbol mensaje de conflicto?
  • He visto este comportamiento antes también, pero no estoy seguro de cuál es su causa. Es que cuando se agrega un dir y cambiarle el nombre antes de que cometió tal vez?
  • Yo también la experiencia de este comportamiento y no he sido capaz de encontrar una razón. Siempre he atribuyó a «la forma en SVN obras». Me vuelve loco.
  • Albin, el mensaje se pierde de GNU búfer de pantalla de la gama :/
  • vext01, dir agregar llevó al svn manera antes de svn mv. Los archivos dentro de recibido de trabajo y fueron cometidos antes de la svn mv.
  • Albin, me replica el problema en su totalidad, y no el mensaje.
  • Por qué? Debido a la Subversión diseñador de pensamiento que copiar/borrar es un reemplazo adecuado para cambiar el nombre. No es. Y no es porque perder información. Las informaciones que la mezcla se debe de hacer un merge en el nuevo nombre de la entidad. Un cambio de nombre por copiar/borrar sólo funcionará de ninguna combinación es necesaria. Y por otro lado se completa y absolutamente fallar cuando la mezcla sea necesario. La única forma de solucionarlo es haciendo cambiar el nombre de una primera clase de operación atómica. Y para ello la subversión diseñador debe admitir que se había equivocado acerca de la copia/borrar todo junto.

InformationsquelleAutor Lloeki | 2010-10-15

4 Comentarios

  1. 67

    svn mv me funciona:

    C:\svn\co>svn mv my_dir new_dir
    A         new_dir
    D         my_dir\New Text Document.txt
    D         my_dir
    
    
    C:\svn\co>svn commit -m foo
    Raderar             my_dir
    Lägger till         new_dir
    
    Arkiverade revision 2.
    
    C:\svn\co>
    

    Lo siento por el sueco salida de svn.

    Debe haber algo más que está equivocado en su caso.

    Edición:

    Como se señaló en los comentarios por Lloeki

    Para reproducir el comportamiento también la necesidad de actualizar y cometer un archivo contenido en la carpeta, pero no la actualización de la carpeta en sí.

    archivo de cometer crea un nuevo rev n en el
    repo, pero los metadatos no es
    actualizado (como siempre lo ha de ser, ver svn
    registro después de commit) , así dir
    los metadatos en rev n-1. Sigue
    que svn no cometer, porque de la
    los metadatos diff, y no actualizar
    porque hay, de hecho, un conflicto en
    el dir: actualización de los metadatos vs eliminar.

    El comportamiento «esperado» y la «solución» es para actualizar la copia de trabajo antes de la emisión de la svn rename comando.

    • Encontrar ese ‘algo más’ es en realidad parte de la pregunta 🙂 Ahora modificar el Texto Nuevo Document.txt, el commit, luego mv la dir y cometer de nuevo.
    • sí modificando el archivo de texto reproduce el árbol de conflicto. Realmente parece un error para mí, has buscado en el issue tracker en subversion.apache.org y/o se presentó un informe de error no?
    • Finalmente he encontrado la razón, que tiene sentido en un subvertido manera: archivo de cometer crea un nuevo rev n en la repo, pero los metadatos no se actualiza (como siempre lo ha de ser, ver svn log después de commit) , así dir metadatos en rev n-1. De ello se desprende que svn no cometer, porque de los metadatos diff, y no actualizar porque no hay, de hecho, un conflicto en el dir: actualización de los metadatos vs eliminar.
    • Ya que usted me puso en la pista, actualizar tu respuesta y voy a validar.
    • Los de arriba «svn mv mi_dir dir_nuevo» trabajó para mí. Después de que yo pudiera uso normal svn commit del gui de windows
  2. 8

    OK, me topé con este – y, finalmente, puede reconstruir el problema con una simple sesión de terminal: el problema ocurre si svn mv (mover/cambiar el nombre de un archivo; a continuación, se comprometen a que el cambio; entonces (sin haciendo un svn update primera), svn mv el directorio principal del archivo cuyo mover/renombrar fue previamente comprometidos – y finalmente hacer un svn commit en el cambio de nombre de directorio o como aceptado respuesta pone: «también la necesidad de actualizar y cometer un archivo contenido en la carpeta pero no actualización de la carpeta en sí«; pero todo esto ejecutado en un padre (o más bien, antepasado) directorio. Aquí la línea de comandos de registro de demostrar el problema:

    $ cd /tmp
    $ svnadmin create myrepo
    $ svn co file:///tmp/myrepo myrepo-wc
    Checked out revision 0.
    
    $ cd myrepo-wc/
    $ mkdir -p dir1/dir2/dir3
    $ svn add dir1/
    A         dir1
    A         dir1/dir2
    A         dir1/dir2/dir3
    
    $ svn ci -m 'add dir1/'
    Adding         dir1
    Adding         dir1/dir2
    Adding         dir1/dir2/dir3
    
    Committed revision 1.
    
    $ echo test1 >> dir1/dir2/dir3/test1.txt
    $ echo test2 >> dir1/dir2/dir3/test2.txt
    $ svn add dir1/
    svn: warning: 'dir1' is already under version control
    $ svn add dir1/*
    svn: warning: 'dir1/dir2' is already under version control
    $ svn add dir1/dir2/dir3/*
    A         dir1/dir2/dir3/test1.txt
    A         dir1/dir2/dir3/test2.txt
    $ svn status
    A       dir1/dir2/dir3/test2.txt
    A       dir1/dir2/dir3/test1.txt
    $ svn ci -m 'add dir1/dir2/dir3/*'
    Adding         dir1/dir2/dir3/test1.txt
    Adding         dir1/dir2/dir3/test2.txt
    Transmitting file data ..
    Committed revision 2.
    
    $ svn mv dir1/dir2/dir3/test2.txt dir1/dir2/dir3/test2X.txt
    A         dir1/dir2/dir3/test2X.txt
    D         dir1/dir2/dir3/test2.txt
    $ svn status
    D       dir1/dir2/dir3/test2.txt
    A  +    dir1/dir2/dir3/test2X.txt
    $ svn ci -m 'mv dir1/dir2/dir3/test2.txt dir1/dir2/dir3/test2X.txt'
    Deleting       dir1/dir2/dir3/test2.txt
    Adding         dir1/dir2/dir3/test2X.txt
    
    Committed revision 3.
    
    $ svn status
    $ svn mv dir1/dir2/dir3 dir1/dir2/dir3X
    A         dir1/dir2/dir3X
    D         dir1/dir2/dir3/test2X.txt
    D         dir1/dir2/dir3/test1.txt
    D         dir1/dir2/dir3
    $ svn status
    D       dir1/dir2/dir3
    D       dir1/dir2/dir3/test2X.txt
    D       dir1/dir2/dir3/test1.txt
    A  +    dir1/dir2/dir3X
    D  +    dir1/dir2/dir3X/test2.txt
    $ svn ci -m 'mv dir1/dir2/dir3 dir1/dir2/dir3X'
    Deleting       dir1/dir2/dir3
    svn: Commit failed (details follow):
    svn: Directory '/dir1/dir2/dir3' is out of date
    $ svn status
    D       dir1/dir2/dir3
    D       dir1/dir2/dir3/test2X.txt
    D       dir1/dir2/dir3/test1.txt
    A  +    dir1/dir2/dir3X
    D  +    dir1/dir2/dir3X/test2.txt
    $ svn up
       C dir1/dir2/dir3
    At revision 3.
    Summary of conflicts:
      Tree conflicts: 1
    

    Y esto es lo que debería haber sido – hacer una svn up después de que el archivo mover/renombrar fue comprometidos; nota cómo la versión de los números reportados por svn status -v cambiar después de que el svn update comando:

    $ cd /tmp
    $ rm -rf myrepo*
    
    $ svnadmin create myrepo
    $ svn co file:///tmp/myrepo myrepo-wc
    Checked out revision 0.
    
    $ cd myrepo-wc/
    $ mkdir -p dir1/dir2/dir3
    $ svn add dir1/
    A         dir1
    A         dir1/dir2
    A         dir1/dir2/dir3
    $ svn ci -m 'add dir1/'
    Adding         dir1
    Adding         dir1/dir2
    Adding         dir1/dir2/dir3
    
    Committed revision 1.
    
    $ echo test1 >> dir1/dir2/dir3/test1.txt
    $ echo test2 >> dir1/dir2/dir3/test2.txt
    $ svn add dir1/dir2/dir3/*
    A         dir1/dir2/dir3/test1.txt
    A         dir1/dir2/dir3/test2.txt
    $ svn status
    A       dir1/dir2/dir3/test2.txt
    A       dir1/dir2/dir3/test1.txt
    $ svn ci -m 'add dir1/dir2/dir3/*'
    Adding         dir1/dir2/dir3/test1.txt
    Adding         dir1/dir2/dir3/test2.txt
    Transmitting file data ..
    Committed revision 2.
    
    $ svn mv dir1/dir2/dir3/test2.txt dir1/dir2/dir3/test2X.txt
    A         dir1/dir2/dir3/test2X.txt
    D         dir1/dir2/dir3/test2.txt
    $ svn status
    D       dir1/dir2/dir3/test2.txt
    A  +    dir1/dir2/dir3/test2X.txt
    $ svn ci -m 'mv dir1/dir2/dir3/test2.txt dir1/dir2/dir3/test2X.txt'
    Deleting       dir1/dir2/dir3/test2.txt
    Adding         dir1/dir2/dir3/test2X.txt
    
    Committed revision 3.
    
    $ svn status
    $ svn status -v
                     0        0  ?           .
                     1        1 username dir1
                     1        1 username dir1/dir2
                     1        1 username dir1/dir2/dir3
                     3        3 username dir1/dir2/dir3/test2X.txt
                     2        2 username dir1/dir2/dir3/test1.txt
    $ svn up
    At revision 3.
    $ svn status -v
                     3        3 username .
                     3        3 username dir1
                     3        3 username dir1/dir2
                     3        3 username dir1/dir2/dir3
                     3        3 username dir1/dir2/dir3/test2X.txt
                     3        2 username dir1/dir2/dir3/test1.txt
    $ svn mv dir1/dir2/dir3 dir1/dir2/dir3X
    A         dir1/dir2/dir3X
    D         dir1/dir2/dir3/test2X.txt
    D         dir1/dir2/dir3/test1.txt
    D         dir1/dir2/dir3
    $ svn status
    D       dir1/dir2/dir3
    D       dir1/dir2/dir3/test2X.txt
    D       dir1/dir2/dir3/test1.txt
    A  +    dir1/dir2/dir3X
    $ svn ci -m 'mv dir1/dir2/dir3 dir1/dir2/dir3X'
    Deleting       dir1/dir2/dir3
    Adding         dir1/dir2/dir3X
    
    Committed revision 4.
    
    $ svn status
    $ svn status -v
                     3        3 username .
                     3        3 username dir1
                     3        3 username dir1/dir2
                     4        4 username dir1/dir2/dir3X
                     4        4 username dir1/dir2/dir3X/test2X.txt
                     4        4 username dir1/dir2/dir3X/test1.txt
    $ svn up
    At revision 4.
    $ svn status -v
                     4        4 username .
                     4        4 username dir1
                     4        4 username dir1/dir2
                     4        4 username dir1/dir2/dir3X
                     4        4 username dir1/dir2/dir3X/test2X.txt
                     4        4 username dir1/dir2/dir3X/test1.txt
    

    Y como OP – dijo- debería olvidar hacer la svn update antes de que un nuevo mover/cambiar el nombre de+cometer, y el «Cometer error» se ha producido -, entonces puede utilizar svn resolve --accept working -R . a ser capaz de terminar el cometer la acción.

  3. 1

    Esto funcionó para mí:

    vi someotherfile
    ...various changes to the other file
    svn mv olddir newdir
    svn commit -m"Moved olddir out of the way" olddir
    svn commit -m"New location of olddir" newdir
    svn update
    svn commit -m"Changed someotherfile" someotherfile
    

    Sospecho que hay varias otras maneras posibles de la ronda, y de garantizar que hubo un directorio limpio antes de hacer el svn mv también han hecho el truco.

  4. 0

    Uno podría pensar en un escenario en el que el directorio ha sido cambiado en el repositorio por otro usuario. El cambio de nombre de la misma carpeta en su copia de trabajo, pueden desencadenar árbol de conflictos durante la confirmación.

    La resolución de los conflictos muestra cómo resolver ‘árbol de los conflictos» en subversión.

    • Estoy en un único desarrollador escenario donde no se produce el cambio.

Dejar respuesta

Please enter your comment!
Please enter your name here