Retracta el logging accidental

Estás utilizando subversión y accidentalmente registras algún código antes de que esté listo. Por ejemplo, a menudo: a) comprobo un código, luego b) edito un poco, luego c) presiono arriba, intro para repetir el command anterior que lamentablemente fue un check-in.

¿Es posible retractarse de un logging accidental del server con subversión?

NB: ESTE PROBABLEMENTE NO FUNCIONARÁ EN LAS VERSIONES ACTUALES DE LA SUBVERSIÓN Y ES UNA IDEA MALA, pero la dejé aquí para get información

NB: Normalmente, cuando se ha registrado por error, simplemente debe revertir el compromiso; consulte las otras respuestas a esta pregunta. Sin embargo, si quiere saber cómo deshacer realmente los efectos de la confirmación y cambiar el repository como estaba antes, hay algunas explicaciones a continuación:

Esto no es lo que normalmente desea, pero si realmente desea eliminar la versión comprometida real del repository, entonces puede hacer una desagradable reversión en el repository de la siguiente manera (esto supone que $REV está configurado en la última revisión, que estás eliminando):

  • Haga una copy de security de su repository primero ya que estos cambios pueden romperlo (y lea las suposiciones a continuación)
  • Revierte tu copy local a la revisión anterior para que no se confunda ( svn revert -r $((REV-1)) )
  • En el repository, elimine db/revs/$REV y db/revprops/$REV
  • En el repository, elimine db/current y (para subversión 1.6 o superior) db/rep-cache.db , y ejecute svnadmin recover .
  • (Posiblemente) ajuste los permissions en db/rep-cache.db para evitar bashs de escribir errores de database de solo lectura

Todo esto asume:

  • Estás usando un repository basado en fsfs
  • Lanzamiento de Subversion superior a 1.5.0 (de lo contrario, debe editar manualmente db/current y cambiar el número de revisión en lugar de ejecutar svnadmin recover . ) svnadmin recover .
  • No se han confirmado otras revisiones posteriores
  • Tiene acceso de escritura al sistema de files del repository
  • No tienes miedo de que alguien más intente acceder a él mientras haces lo anterior

Lo hice cuando un gran file fue enviado a un repository que no quería permanecer en la historia (y espejos, etc.) para siempre; de ninguna manera es una práctica ideal o normal …

Consulte el SVNBook , específicamente la sección 'Deshacer cambios' y la fusión inversa.

Otro uso común para svn merge es retrotraer un cambio que ya se ha confirmado. Supongamos que estás trabajando felizmente en una copy de trabajo de / calc / trunk, y descubres que el cambio realizado en la revisión 303, que cambió integer.c, es completamente incorrecto. Nunca debería haber sido cometido. Puede usar svn merge para "deshacer" el cambio en su copy de trabajo, y luego confirmar la modificación local en el repository. Todo lo que necesita hacer es especificar una diferencia inversa:

$ svn merge -r 303: 302 http://svn.example.com/repos/calc/trunk

Para aclarar, su cambio inicial aún estará en el repository . Pero ahora lo has retractado en una revisión posterior. es decir, el repository ha capturado todos sus cambios (¡que es lo que realmente quiere!) ¡A less que haya registrado una contraseña de text simple o similar!

ADVERTENCIA : La respuesta aceptada (por David Fraser) debería funcionar con un repository SVN 1.5, pero con SVN 1.6 también debe eliminar db/rep-cache.db antes de la próxima confirmación o se corromperá su repository y puede que no se dé count hasta la próxima vez que intente una compra completa. He visto fallas posteriores completas con un error de "encabezado de representación mal formado".

¿Qué es rep-cache.db, puede preguntar? La documentation en el layout de FSFS dice que perderá "capacidades de intercambio de representantes" si elimina este file; sin embargo, se volverá a crear en tu próxima confirmación. El intercambio de representaciones se agregó en 1.6 .

Usando TortoiseSVN, select Mostrar logging y ubique la revisión a la que desea revertir. Desde el menu contextual, selecciona Revertir a esta revisión. Esto realiza una fusión inversa en su copy de trabajo, por lo que tendrá que confirmar su copy de trabajo para finalizar la operación.

Ver también ¿Cómo hacemos un seguimiento de la twig de nuestra copy de trabajo? 🙂

Si lo que quieres decir es, ¿cómo elimino limpiamente el historial de un checkin accidental? Esto es difícil.

svn no le permite deshacer nada, ya que guarda las revisiones como sets de cambios. Sin embargo, hay algunas herramientas que le permiten hacer casi cualquier cosa en un volcado de un repository. Usted podría :

  1. Deposita tu repository.

  2. Utilice svndumpfilter desde las herramientas de administración svn para deshacerse de la comprobación.

  3. Póngalo nuevamente en el repository.

Pero esto puede arruinar completamente su repository, así que nunca intente hacer esto, a less que sepa absolutamente lo que está haciendo y tenga todo respaldado.

Sí, esto es realmente para lo que es Subversion.

Lo que necesita hacer es simplemente replace su copy con la revisión previa en el repository SVN.

Hay varias opciones:

  1. Reemplazar con revisión
  2. Reemplazar con URL
  3. Lo último del repository (pero en tu caso, ya tienes el último)
  4. Reemplazar con Branch

Pero le recomiendo que haga lo siguiente antes de replace su copy local:

  1. Haga una 'Comparar con Repositorio / Revisión / URL'.

No se puede eliminar la revisión: varias respuestas parecen ser totalmente erróneas. Pero puede cambiar el post de logging para indicar que no fue intencionado. Los loggings no cuestan mucho, así que tener uno extra no es un gran problema.

Yo lo dudaría. Una de las ideas principales de un control de código fuente es que un repository no pierde ningún historial. No puedes borrar el historial Lo mejor que puede hacer es get una versión anterior y sobrescribir la actual con eso. Pero los loggings de historial aún mostrarán su error.

(Offtopic: ¿Qué tipo de IDE estás usando que hace algo así?)

no puede retractarse de la revisión, lo máximo que puede hacer es volver a la revisión anterior y realizar otra revisión.

Para comentar sobre esto también: Esta es una serie de commands que hice en un repository para revertirlo de la revisión 2 a la revisión 1. Sin embargo, necesitaría registrarse al final.

 Last login: Mon Apr 13 16:01:34 on ttys004 [wlynch@orange ~] cd /tmp [wlynch@orange /tmp] svnadmin create foo [wlynch@orange /tmp] svn co file:///tmp/foo foo-repo Checked out revision 0. [wlynch@orange /tmp] cd foo-repo/ [wlynch@orange foo-repo] ls [wlynch@orange foo-repo] touch blah [wlynch@orange foo-repo] touch repl [wlynch@orange foo-repo] touch bar [wlynch@orange foo-repo] svn add * A bar A blah A repl [wlynch@orange foo-repo] svn ci Adding bar Adding blah Adding repl Transmitting file data ... Committed revision 1. [wlynch@orange foo-repo] echo "hi" > bar [wlynch@orange foo-repo] echo "oh no" > blah [wlynch@orange foo-repo] svn ci Sending bar Sending blah Transmitting file data .. Committed revision 2. [wlynch@orange older-foo] svn diff -r 1:2 file:///tmp/foo Index: bar =================================================================== --- bar (revision 1) +++ bar (revision 2) @@ -0,0 +1 @@ +hi Index: blah =================================================================== --- blah (revision 1) +++ blah (revision 2) @@ -0,0 +1 @@ +oh no [wlynch@orange foo-repo] svn diff -r 1:2 file:///tmp/foo | patch -R patching file bar patching file blah 

A veces es necesario editar el repository en el server, por ejemplo, cuando ha cometido accidentalmente una contraseña que es difícil de cambiar. Este es un método que creo que es completamente seguro (la respuesta de @David Fraser me causó corrupción en repositorys). Nota: este método solo eliminará las revisiones desde el final del repository, por lo que es más útil si observa su error de inmediato.

  1. Informe a todos sus usuarios que el repository se desconectará y que deberán crear una nueva salida del server.
  2. Lleve el repository fuera de línea, tome una copy de security y mueva el repository principal a un lugar seguro con un nombre como reponame_old.
  3. Vuelque su repository a una representación de un solo file, dejando las revisiones no deseadas al final:
    • svnadmin dump -r 0:N > reponame.dump
    • por ejemplo, svnadmin dump -r 0:6610 > reponame.dump eliminará las revoluciones 6611 en adelante
    • Tenga en count que el file repodump puede ser el doble del tamaño de su carpeta repo.
  4. Cree un nuevo repository para cargar estas revisiones en:
    • svnadmin create reponame
  5. Cargue el set recortado de revisiones en el nuevo repository
    • svnadmin load reponame < reponame.dump
  6. Aplique las personalizaciones necesarias a su nuevo repository (por ejemplo, ganchos) y devuélvalo al service.
    • Estamos usando el server VisualSVN, así que tuvimos que restaurar el file conf \ VisualSVN-WinAuthz.ini.
    • También vimos un comportamiento extraño hasta que reiniciamos el server, por lo que VisualSVN puede almacenar en caching el estado de repository; YMMV con otras configuraciones de alojamiento.
  7. No olvides eliminar la copy de security con los datos secretos o ponerla en un lugar seguro.
  8. Indique a todos los usuarios que realicen una nueva svn checkout desde el server de repository.