Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Ève

Extraire une partie d'un dépôt Subversion alors qu'il y a eu un renommage

Première rédaction de cet article le 21 juillet 2009


Le VCS Subversion offre la possibilité d'exporter une partie d'un dépôt (avec svndumpfilter) mais il offre aussi la possibilité de renommer, de déplacer un sous-arbre d'un point du dépôt à un autre, et ces deux fonctions s'entendent parfois mal.

Le mécanisme normal de filtrage, avec svndumpfilter, est bien documenté. On exporte le dépôt avec svnadmin dump, on le filtre avec svndumpfilter et hop :

% svnadmin dump /my/repository | svndumpfilter include /quizzie > quizzie.svn

et on a un dump quizzie.svn qui ne contient que le sous-arbre /quizzie. Mais la documentation prévient bien que cela peut entraîner des problèmes : « It is possible that at some point in the lifetime of your repository, you might have copied a file or directory from some location that svndumpfilter is excluding, to a location that it is including. In order to make the dump data self-sufficient, svndumpfilter needs to still show the addition of the new path - including the contents of any files created by the copy - and not represent that addition as a copy from a source that won't exist in your filtered dump data stream. » Bref, le filtrage peut aboutir à exclure des moments de l'histoire, sans lesquels on ne peut pas reconstituer un fil cohérent. Au moment de la restauration, on aura des problèmes comme :

% svnadmin load /my/new-repository < quizzie.svn
<<< Started new transaction, based on original revision 7
svnadmin: File not found: transaction '8-8', path 'quizzie/new-name/bar/myfile'
     * editing path : quizzie/new-name/bar/myfile ...

Prenons l'exemple suivant, tiré d'une expérience réelle : un répertoire a été déplacé de /foo/old-name en /other/new-name. On veut exporter le dépôt pour le passer à quelqu'un mais, comme le dépôt contient à la fois des choses privées et des choses publiques, on veut filtrer et ne garder que /other/new-name/bar (et son ancien nom, /foo/old-name/bar). Ce faisant, la révision où a été faite le renommage sera exclue (car située plus haut dans l'arbre). Cela produira l'erreur ci-dessus à la restauration (vous pouvez essayer, avec le script subversion-filtering-problem.sh).

Il existe plusieurs solutions à ce problème. Par exemple, il semble que des alternatives à svndumpfilter comme svndumpfilter2 ou svndumpfilter3 permettent d'éviter ce problème. Je n'ai pas eu de succès avec ces programmes (et je note que, dans les deux cas, passer un nom de répertoire inexistant ne produit aucune erreur, ce qui semble indiquer que le programmeur ne teste pas ce que fait son programme).

Ma solution a donc été de trouver la révision où est faite le renommage, de dumper (en filtrant) jusqu'à cette révision (exclue), de dumper (avec l'option --incremental) à partir de cette révision (également exclue) et, au rechargement, de faire un svn rename moi-même. La version modifiée du script, subversion-filtering-solution.sh, fait cela.

À noter que cette question a été discutée sur Server Fault. Vous y trouverez peut-être davantage de détails.

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)