Elimina il file con tutta la cronologia dal repository svn

C’è un modo per eliminare il file dal repository svn inclusa tutta la sua cronologia? Questo problema emerge quando voglio sbarazzarmi di file binari di grandi dimensioni che risiedono in repository.

Conosco solo un approccio che potrebbe aiutare in questa situazione:

  1. Scarica tutti i pronti contro termine con l’aiuto dell’utilità svnadmin .
  2. Filtra il file scaricato con grep . Grep dovrebbe usare il nome del file e scrivere nell’altro file di dump
  3. Importa l’ultimo dump-file con svnadmin

Ma questo è troppo complicato e inaffidabile. Forse c’è un’altra soluzione?

Di recente questo è diventato molto più semplice con il comando svndumpfilter . I dettagli sono disponibili nella documentazione di sovversione qui . Fondamentalmente, per evitare conflitti (spiegato qui ), prende un repo dump e ripristina ogni commit, includendo o escludendo un dato prefisso di file. Sintassi di base:

 svndumpfilter exclude yourfileprefix < yourdump > yournewdump 

Escludi è probabilmente ciò che cerca il richiedente la domanda, ma puoi anche usare include, per esempio, estrarre un sottoalbero del repository in modo da eseguirlo come suo repository.

L’ultima revisione di sovversione in sovversione (molto meta) può anche seguire schemi globali. Recentemente ho dovuto rimuovere tutti i pdf da un repository ed è stato fatto molto facilmente in questo modo:

 svndumpfilter exclude --pattern '*.pdf' < dump > dump_nopdfs 

Ulteriori informazioni sull’utilizzo possono essere trovate chiamando svndumpfilter help e svndumpfilter help exclude .

Ma questo è troppo complicato e inaffidabile.

Non saprei dire perché questo non dovrebbe essere considerato affidabile. Tuttavia, se si desidera eliminare completamente il file, la cronologia e tutto quanto, a prescindere dall’effetto sulle revisioni precedenti a cui questo file faceva parte, esiste solo un modo per farlo e in questo modo è davvero complicato. E giustamente. SVN è uno strumento con un unico objective: mai e poi mai perdere alcun file, anche dopo che è stato cancellato. Costringerlo a fare altrimenti dovrebbe essere difficile.

Stavo affrontando un problema simile, tranne che avevo bisogno di rimuovere più file, non solo un file, e inoltre siamo su Subversion 1.6 che non supporta la direttiva – patern.

– backup SVN corrente

 $ cp -R /svn /svnSAVE 

– repository di dump

 $ svnadmin dump /svn/root > svnDump 

– Crea nuovo dump escludendo il file molto grande

 $ svndumpfilter exclude "/path/file.csv" < svnDump > newSvnDump0 -- {note: should see a message like this}: -- Dropped 1 node: -- '/path/file.csv' 

– crea un altro nuovo dump escludendo un altro file molto grande

 $ svndumpfilter exclude "/path/anotherFile.csv" < newSvnDump0 > newSvnDump1 

– rimuovi il vecchio svn

 $ rm -rf /svn 

– ricreare le directory svn

 $ mkdir -p /svn/root 

– ricreare l’SVN

 $ svnadmin create /svn/root 

– ripopolare il repository fresco con la discarica

 $ cat newSvnDump1 | svnadmin load /svn/root 

– aggiorna i file conf dalla copia salvata alla nuova copia …

 $ cp /svnSAVE/root/conf/* /svn/root/conf 

Ora il repository non dovrebbe contenere i 2 file di grandi dimensioni “file.csv” e “anotherFile.csv”

Sono d’accordo con la proposta di McDowell, ma vorrei suggerire di prendere in considerazione la sostituzione del file di grandi dimensioni con un file di testo che contiene semplicemente l’hash del file per la voce rimossa.

Ad esempio, se si dispone di un numero enorme di file .o per la verifica accidentale di una directory di costruzione, ciò potrebbe non essere appropriato. Ma se stai rimuovendo una serie di artefatti binari che non vuoi da una directory che include una serie di artefatti binari che vuoi, sei ad alto rischio di fare un errore costoso. Come minimo, considera di rimuoverli dal trunk e dalla maggior parte dei rami, ma lasciando un ramo di funzionalità pieno di file di testo segnaposto con l’hash del file binario originale. Questo può essere sufficiente per capire cosa è successo dopo, verificare che una copia vagante che non dovrebbe essere stata cancellata sia in realtà il file giusto e rimetterla sotto controllo di revisione.

E, ovviamente, restituisci l’intero repo a qualcosa di di sola lettura, come un paio di M-Disc o qualcosa del genere, prima ancora di pensare a fare qualcosa del genere.