Cómo recuperarse de un cambio de nombre no deseado usando git-svn: "La transacción está desactualizada"

Estoy usando git-svn. He movido el archivo 'A' a 'B' y estoy actualizado con el svn HEAD (usando git svn rebase). Puedo cometer todos los otros cambios sin problemas. Ahora he decidido que quiero mover 'B' a 'A' y confirmar ese cambio.Cómo recuperarse de un cambio de nombre no deseado usando git-svn: "La transacción está desactualizada"

Cuando hago el movimiento y comprometerse a mi maestro local que trabaja muy bien, pero me sale el siguiente cuando se hace una git svn dcommit:

Transaction is out of date: Out of date: 'A' in transaction '3652-1' at /opt/local/libexec/git-core/git-svn line 570

así que traté de copiar y borrar en un separada cometer lo que resultó en :

Item already exists in filesystem: File already exists: filesystem '/usr/svn/db', transaction '3652-1', path 'A' at /opt/local/libexec/git-core/git-svn line 4735

me he recuperado de esta situación con la llanura svn mediante el uso de las soluciones como la que se describe en el documentation, pero no sé cómo recuperar con git-svn. ¿Qué está pasando y cómo lo soluciono?

Fuente

2010-05-27 iwein

Eliminar .git/svn no funcionó para mí. En su lugar, así es como he resuelto:

suprimido el directorios ofensivos desde el repositorio
git svn rebase
(pero no estoy seguro de que esto es necesario En retrospectiva, creo que podría haber saltado este paso). Durante la rebase, hubo algunos conflictos. Para cada conflicto, resolví los conflictos en el editor de texto, luego usé git add <file-in-conflict> y luego git rebase --continue
Después de que la base de datos se haya completado correctamente, git svn dcommit se ejecutó correctamente.

Fuente

2012-08-21 14:06:10 Upgradingdave

¿Alguien puede confirmar que esto funciona (también)? Parece que recibió un voto negativo, pero no sé por qué. – iwein

@iwein: Esta funcionó para mí y la respuesta aceptada no. –

Esto funcionó para mí también, y no necesitaba el primer paso (Eliminar directorios ofensivos). –

No puedo afirmar que entiendo realmente lo que sucede bajo el capó en git-svn en este caso (aunque el problema SVN subyacente tiene mucho sentido). Mi estrategia habitual cuando git-svn se confunde de alguna manera es volar el directorio de metadatos .git/svn (como en this post). Esto casi siempre me salva de problemas de sincronización extraños entre los repositorios git y SVN.

Fuente

2010-11-29 14:37:04

Gracias por la entrada. ¿Podría darnos un pequeño detalle sobre cómo el problema svn tiene mucho sentido? Intentaré reproducirlo y veré si funciona el voladura del directorio .git/svn. Recuerdo vagamente que en realidad hice un clon nuevo y que el problema aún estaba allí. – iwein

Parece una edición de una copia de trabajo de "revisión mixta", donde alguna parte de la copia de trabajo se ha actualizado a una revisión diferente y más antigua que el resto del WC. Pero realmente no puedo decir qué partes están desactualizadas. Esto se describe en parte aquí: http://svnbook.red-bean.com/en/1.5/svn.basic.in-action.html#svn.basic.in-action.mixedrevs. ¿Funcionó el truco de eliminación de metadatos? –

No logré probarlo más debido a la volatilidad de mis bases de códigos locales.Supongamos que funciona hasta que alguien descubra que no :) – iwein

Sucedió conmigo cuando interrumpí el proceso dcommit.

Siga estos pasos para recuperarse de errores:

git svn rebase
Usted recibirá conflictos en los archivos. Resuelva los conflictos & luego git add filename (en el que se produjo el conflicto) para cada archivo.
Ahora haz git svn dcommit. Será empujado al control remoto con éxito.

Fuente

2014-11-25 10:49:22

Detalles interesantes. Pero la receta es la misma que la aceptada. – iwein

Cómo recuperarse de un cambio de nombre no deseado usando git-svn: "La transacción está desactualizada"

Respuesta

Cuestiones relacionadas