Ritirare il check-in accidentale

Stai usando la sovversione e accidentalmente controlli qualche codice prima che sia pronto. Per esempio, io spesso: a) controllo un po ‘di codice, poi b) modifica un po’, poi c) premi su, inserisci per ripetere il comando precedente che sfortunatamente era un check-in.

È ansible ritirare tale controllo accidentale dal server con subversion?

NB: QUESTO PROBABILMENTE NON FUNZIONERÀ SULLE VERSIONI CORRENTI DI SUBVERSIONE ED È UN’IDEA MALE – ma l’ho lasciato qui per informazioni

NB: Normalmente quando ti sei registrato per errore, dovresti semplicemente ripristinare il commit – vedi le altre risposte a questa domanda. Tuttavia, se vuoi sapere come annullare effettivamente gli effetti del commit e modificare il repository come prima, ci sono alcune spiegazioni di seguito:

Questo non è quello che si desidera normalmente, ma se si desidera veramente rimuovere la versione impegnata effettiva dal repository, è ansible eseguire un rollback in modo anomalo sul repository come segue (questo presuppone che $REV sia impostato sull’ultima revisione, che stai rimuovendo):

  • Effettua il backup del tuo repository prima, dato che queste modifiche potrebbero interromperlo (e leggere le ipotesi di seguito)
  • Ripristina la copia locale nella revisione precedente in modo che non venga confusa ( svn revert -r $((REV-1)) )
  • Nel repository, rimuovere db/revs/$REV e db/revprops/$REV
  • Nel repository, rimuovere db/current e (per subversion 1.6 o versione successiva) db/rep-cache.db ed eseguire il svnadmin recover .
  • (Possibilmente) regolare le autorizzazioni su db/rep-cache.db per impedire il tentativo di scrivere errori di database di sola lettura

Tutto ciò presuppone:

  • Stai utilizzando un repository basato su fsfs
  • Rilascio di Subversion superiore a 1.5.0 (altrimenti è necessario modificare manualmente db/current e modificare il numero di revisione piuttosto che eseguire il svnadmin recover . ) svnadmin recover .
  • Non sono state commesse altre revisioni successive
  • Hai accesso in scrittura al filesystem del repository
  • Non hai paura che qualcun altro cerchi di accedervi mentre fai quanto sopra

L’ho fatto quando un file enorme è stato impegnato in un repository che non volevo rimanere nella cronologia (e nei mirror ecc.) Per sempre; non è in alcun modo ideale o pratica normale …

Vedere SVNBook , in particolare la sezione ” Annulla modifiche” e invertire la fusione.

Un altro uso comune per svn merge è il rollback di una modifica che è già stata commessa. Supponiamo che stiate lavorando felicemente su una copia funzionante di / calc / trunk, e scoprite che la modifica fatta nella revisione 303, che ha cambiato l’intero.c, è completamente sbagliata. Non avrebbe mai dovuto essere impegnato. È ansible utilizzare svn merge per “annullare” la modifica nella propria copia di lavoro e quindi eseguire il commit della modifica locale nel repository. Tutto quello che devi fare è specificare una differenza di inversione:

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

Per chiarire, la tua modifica iniziale sarà ancora nel repository . Ma ora lo hai ritrattato in una revisione successiva. cioè il repository ha catturato tutte le tue modifiche (che è proprio quello che vuoi! A meno che tu abbia controllato una password in chiaro o simile!)

ATTENZIONE : la risposta accettata (da David Fraser) dovrebbe funzionare con un repository SVN 1.5, ma con SVN 1.6 è necessario eliminare anche db/rep-cache.db prima del prossimo commit o si corrompe il repository e potrebbe non realizzarlo fino la prossima volta proverai un checkout completo. Ho visto i successivi checkout completi fallire con un errore “header di rappresentazione non valido”.

Cosa è rep-cache.db, potresti chiedere? La documentazione sul layout di FSFS dice che perderai “funzionalità di condivisione delle risposte” se elimini questo file; tuttavia, verrà ricreato al prossimo commit. La condivisione della rappresentazione è stata aggiunta in 1.6 .

Utilizzando TortoiseSVN, selezionare Mostra registro e individuare la revisione che si desidera ripristinare. Dal menu di scelta rapida, selezionare Ripristina questa revisione. Questo esegue un’unione inversa nella tua copia di lavoro, quindi dovrai impegnare la tua copia di lavoro per completare l’operazione.

Vedi anche Come teniamo traccia della filiale della nostra copia di lavoro? 🙂

Se quello che intendevi è, come faccio a rimuovere in modo pulito la cronologia di un controllo accidentale: questo è difficile.

svn non ti permette di annullare nulla poiché salva le revisioni come changeset. Tuttavia, ci sono alcuni strumenti che ti permettono di fare quasi tutto su un dump di un repository. Potresti:

  1. Scarica il tuo repository.

  2. Usa svndumpfilter dagli strumenti di amministrazione di svn per sbarazzarti del checkin.

  3. Rimettilo nel repository.

Ma questo può rovinare completamente il tuo repository, quindi mai e poi mai provare a farlo, a meno che tu non sappia assolutamente quello che stai facendo e che tutto sia supportato.

Non è ansible rimuovere la revisione: parecchie risposte qui sembrano confondere completamente ciò che si desidera. Ma puoi cambiare il messaggio di checkin per indicare che non era intenzionale. I controlli non costano molto, quindi avere uno strano extra non è un grosso problema.

Sì, questo è davvero ciò che è per Subversion.

Quello che devi fare è semplicemente sostituire la tua copia con la revisione precedente nel repository SVN.

Ci sono diverse opzioni:

  1. Sostituire con Revision.
  2. Sostituisci con URL
  3. Ultime dal repository (ma nel tuo caso, hai già l’ultima)
  4. Sostituisci con Branch

Ma ti consiglio vivamente di fare quanto segue prima di sostituire la tua copia locale:

  1. Fai un ‘Confronta con Deposito / Revisione / URL’.

Ne dubito. Una delle idee principali di un controllo del codice sorgente è che un repository non perde alcuna cronologia. Non è ansible eliminare la cronologia. Il meglio che puoi fare è ottenere una versione precedente e sovrascrivere quella attuale con quella. Ma i log della cronologia mostreranno ancora il tuo errore.

(Offtopic: che tipo di IDE stai usando che fa qualcosa del genere?)

non è ansible ritirare la revisione, il massimo che si può fare è tornare alla revisione precedente e fare un altro check-in.

Per commentare anche questo: questa è una serie di comandi che ho fatto su un repository per ripristinarlo dalla revisione 2 alla revisione 1. Avresti comunque bisogno di effettuare il check-in alla fine.

 Last login: Mon Apr 13 16:01:34 on ttys004 [[email protected] ~] cd /tmp [[email protected] /tmp] svnadmin create foo [wly[email protected] /tmp] svn co file:///tmp/foo foo-repo Checked out revision 0. [[email protected] /tmp] cd foo-repo/ [[email protected] foo-repo] ls [[email protected] foo-repo] touch blah [[email protected] foo-repo] touch repl [[email protected] foo-repo] touch bar [[email protected] foo-repo] svn add * A bar A blah A repl [[email protected] foo-repo] svn ci Adding bar Adding blah Adding repl Transmitting file data ... Committed revision 1. [[email protected] foo-repo] echo "hi" > bar [[email protected] foo-repo] echo "oh no" > blah [[email protected] foo-repo] svn ci Sending bar Sending blah Transmitting file data .. Committed revision 2. [[email protected] 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 [[email protected] foo-repo] svn diff -r 1:2 file:///tmp/foo | patch -R patching file bar patching file blah 

A volte è necessario modificare il repository sul server, ad esempio quando hai commesso una password accidentalmente difficile da modificare. Ecco un metodo che ritengo essere completamente sicuro (la risposta di @David Fraser ha causato la corruzione dei repo per me). NB questo metodo rimuoverà solo le revisioni dalla fine del pronti contro termine, quindi è molto utile se noti immediatamente il tuo errore.

  1. Informa tutti i tuoi utenti che il repository è offline e che dovranno creare un nuovo checkout dal server.
  2. Porta il repository offline, fai una copia di backup e sposta il repository principale in un luogo sicuro con un nome come reponame_old.
  3. Scarica il repository su una rappresentazione a file singolo, lasciando le revisioni indesiderate alla fine:
    • svnadmin dump -r 0:N > reponame.dump
    • es. svnadmin dump -r 0:6610 > reponame.dump rimuoverà i svnadmin dump -r 0:6610 > reponame.dump 6611 in poi
    • Si noti che il file repodump potrebbe essere il doppio della dimensione della cartella repo.
  4. Crea un nuovo repository per caricare queste revisioni in:
    • svnadmin create reponame
  5. Carica il set di revisioni ritagliato nel nuovo repository
    • svnadmin load reponame < reponame.dump
  6. Applicare le personalizzazioni necessarie al nuovo repository (ad es. Ganci) e restituirlo al servizio.
    • Stiamo utilizzando il server VisualSVN, quindi è stato necessario ripristinare il file conf \ VisualSVN-WinAuthz.ini.
    • Abbiamo anche visto alcuni comportamenti strani fino al riavvio del server, quindi VisualSVN potrebbe memorizzare nella cache lo stato repo; YMMV con altre configurazioni di hosting.
  7. Non dimenticare di cancellare il backup con i dati segreti o di metterlo in un posto sicuro.
  8. Dì a tutti gli utenti di fare un nuovo svn checkout dal server repo.