web-dev-qa-db-fra.com

Supprimer le fichier avec tout l'historique du référentiel svn

Est-il possible de supprimer un fichier du référentiel svn, y compris tout son historique? Ce problème se pose lorsque je souhaite supprimer un fichier binaire volumineux résidant dans le référentiel. 

Je ne connais qu'une approche qui pourrait aider dans cette situation:

  1. Videz tous les dépôts à l’aide de l’utilitaire svnadmin.
  2. Filtrez le fichier vidé avec grep. Grep devrait utiliser filename et écrire dans l'autre fichier de sauvegarde
  3. Importer le dernier fichier de vidage avec svnadmin

Mais c'est trop compliqué et peu fiable. Peut-être qu'il y a une autre solution?

svnrepositoryversion-control
35
altern

Ceci est récemment devenu beaucoup plus simple avec la commande svndumpfilter. Les détails sont disponibles dans la documentation Subversion ici . Fondamentalement, pour éviter les conflits (expliqué ici ), il faut un repo dump et refait chaque commit, incluant ou excluant un préfixe de fichier donné. Syntaxe de base:

svndumpfilter exclude yourfileprefix < yourdump > yournewdump

Exclure est probablement ce que recherche le demandeur, mais vous pouvez également utiliser include, par exemple, pour extraire un sous-arbre du référentiel afin de le transformer en son propre référentiel.

La dernière révision de Subversion dans Subversion (very meta) peut également prendre des modèles globaux. J'ai récemment eu à supprimer tous les fichiers PDF d'un dépôt et cela s'est fait très facilement, comme ceci:

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

Pour plus d’informations sur l’utilisation, appelez svndumpfilter help et svndumpfilter help exclude.

32
John McDonnell

Mais c'est trop compliqué et peu fiable. 

Je ne saurais pas pourquoi cela ne devrait pas être considéré comme fiable. Toutefois, si vous souhaitez vous débarrasser complètement du fichier, de l'historique et de tous les éléments, quel que soit l'effet sur les révisions précédentes de ce fichier, il n'y a qu'une seule façon de le faire et cette méthode est effectivement compliquée. Et à juste titre. SVN est un outil avec un seul objectif: ne jamais perdre un fichier, même après sa suppression. Le forcer à faire autrement devrait être difficile. 

6
sbi

Je faisais face à un problème similaire, sauf que je devais supprimer plusieurs fichiers, pas seulement un, et nous sommes également sur Subversion 1.6 qui ne prend pas en charge la directive --patern. 

- sauvegarde du SVN actuel

$ cp -R /svn  /svnSAVE

- dépôt de sauvegarde

$ svnadmin dump /svn/root > svnDump

- créer un nouveau dump en excluant le très gros fichier

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

- créer un autre nouveau dump en excluant un autre fichier très volumineux

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

- enlever l'ancien svn 

$ rm -rf /svn

- recréer les répertoires svn

$ mkdir -p /svn/root

- recréer le SVN

$ svnadmin create /svn/root

- repeupler le dépôt avec le dump

$ cat newSvnDump1 | svnadmin load /svn/root

- mettre à jour les fichiers de configuration de la copie sauvegardée dans la nouvelle copie ...

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

Maintenant, le référentiel ne doit pas contenir les 2 gros fichiers "file.csv" et "anotherFile.csv"

3
user3892260

Je suis d'accord avec la proposition de McDowell, mais je voudrais suggérer que vous envisagiez de remplacer le fichier volumineux par un fichier texte contenant simplement le hachage du fichier pour l'entrée supprimée.

Si, par exemple, un nombre considérable de fichiers .o ont été copiés accidentellement dans un répertoire de construction, cela peut ne pas être approprié. Mais si vous supprimez un artefact binaire que vous ne voulez pas d'un répertoire contenant un artefact binaire que vous souhaitez, vous courez un risque élevé de commettre une erreur coûteuse. Au minimum, envisagez de les supprimer du tronc et de la plupart des branches, tout en laissant une branche de fonctionnalité remplie de fichiers texte à espace réservé avec le hachage du fichier binaire d'origine. Cela peut au moins suffire à comprendre ce qui s’est passé plus tard, à vérifier qu’une copie parasite qui n’aurait pas dû être supprimée est bien le bon fichier et à le remettre sous contrôle de révision.

Et, bien évidemment, adaptez toute la mise en pension à quelque chose en lecture seule, comme deux disques M-Discs ou quelque chose du genre, avant même que vous pensiez faire ce genre de choses.

0
breakpoint