Comment diviser un dossier SVN en son propre dépôt lorsqu'il a été renommé ?

Question

Je veux diviser un répertoire d'un grand dépôt Subversion en un dépôt à part entière, et conserver l'historique des fichiers dans ce répertoire.

J'ai d'abord essayé de le faire de la manière habituelle

svnadmin dump /path/to/repo > largerepo.dump
cat largerepo.dump | svndumpfilter include my/directory >mydir.dump

mais cela ne fonctionne pas, car le répertoire a été déplacé et copié au fil des ans et les fichiers ont été déplacés vers d'autres parties du référentiel. Le résultat est un grand nombre de ceux-ci :

svndumpfilter: Invalid copy source path '/some/old/path'

La prochaine chose que j'ai essayé est d'inclure ces /some/old/path au fur et à mesure qu'ils apparaissent et après une longue, longue liste de fichiers et de répertoires inclus, le svndumpfilter se termine, MAIS l'importation du dump résultant ne produit pas les mêmes fichiers que ceux du répertoire courant.

Alors, comment puis-je séparer correctement le répertoire de ce dépôt tout en conservant l'historique ?

EDIT : Je veux spécifiquement trunk/myproj pour être le tronc dans un nouveau dépôt PLUS que le nouveau dépôt n'inclue aucun des autres anciens éléments, c'est-à-dire qu'il ne devrait pas y avoir la possibilité pour quiconque de mettre à jour l'ancienne révision avant la séparation et d'obtenir/voir les fichiers.

La solution svndumpfilter que j'ai essayée aurait permis d'obtenir exactement cela, malheureusement ce n'est pas faisable puisque les chemins/fichiers ont été déplacés. Le site solution par ng n'est pas acceptable puisque c'est essentiellement un clone + suppression des extras qui conserve TOUT l'historique, pas seulement l'historique pertinent de myproj.

Answer 1

J'ai eu un problème similaire en divisant un dépôt

svndumpfilter: Invalid copy source path /dir/old_dir

Ce que j'ai fait pour contourner le problème a été d'inclure les anciens répertoires supplémentaires qu'il demandait, ou que vous savez avoir déplacés. Dans mon cas, j'avais déplacé 3 répertoires dans un autre répertoire.

eg. Déplacement des dossiers A,B,C dans le dossier D

cat project.dump | svndumpfilter include A B C D > new.dump

Cela a semblé résoudre mon problème. J'ai pu séparer le dossier D du reste du Repo. D'un autre côté, lorsque j'ai exclu D, je n'ai pas eu l'erreur, je suppose que c'est parce que la suppression de D ne nécessitait pas les liens/historique vers A,B,C.

Answer 2

Ce problème se produit lorsque l'un des répertoires/fichiers inclus par svndumpfilter a été copié ou déplacé à partir d'une section de l'arbre qui n'est pas incluse.

Pour résoudre le problème, utilisez ce script : svndumpfilter3

Answer 3

J'ai essayé au moins 4 applications différentes pour faire ça, les seules qui a vraiment fonctionné était d'utiliser svndumpfilterIN :

cd /usr/local/bin/
sudo wget --no-check-certificate https://raw.github.com/jasperlee108/svndumpfilterIN/master/svndumpfilter.py
sudo chmod +x svndumpfilter.py
# To be sure nothing will happened on the original repo :
cp -au /path/to/repo /tmp/largerepo.repo/
svnadmin dump /path/to/repo > /tmp/largerepo.dump
svndumpfilter.py /tmp/largerepo.dump --repo=/tmp/largerepo.repo --output-dump=/tmp/mydir.dump include my/directory

Voici ce que j'ai essayé et n'a pas fonctionné :

• http://furius.ca/pubcode/pub/conf/bin/svndumpfilter3.html ( à partir de la réponse précédente )
• Y compris le chemin problématique comme indiqué dans une autre réponse précédente . Problème : j'ai toujours des chemins que je ne veux pas dans la décharge cible.
• svndumpsanitizer (J'ai encore des chemins que je ne veux pas dans le vidage cible aussi)

Answer 4

Cela pourrait potentiellement vous aider : Citation de http://svnbook.red-bean.com/en/1.5/svn.reposadmin.maint.html#svn.reposadmin.maint.replication

Dans Subversion 1.5, svnsync a développé la capacité de mettre en miroir un sous-ensemble d'un dépôt plutôt que la totalité. Le processus de mise en place et de maintenance d'un tel miroir est exactement le même que pour la mise en miroir d'un référentiel entier, sauf qu'au lieu de spécifier l'URL racine du référentiel source lors de l'exécution de svnsync init, vous spécifiez l'URL d'un sous-répertoire dans ce référentiel. La synchronisation vers ce miroir ne copiera alors que les bits qui ont été modifiés dans ce sous-répertoire du dépôt source. Il y a quelques limitations à ce support, cependant. Tout d'abord, vous ne pouvez pas mettre en miroir plusieurs sous-répertoires disjoints du référentiel source dans un seul référentiel miroir - vous devriez plutôt mettre en miroir un répertoire parent qui est commun aux deux. Deuxièmement, la logique de filtrage est entièrement basée sur le chemin, donc si le sous-répertoire que vous mettez en miroir a été renommé à un moment donné dans le passé, votre miroir ne contiendra que les révisions depuis que le répertoire est apparu à l'URL que vous avez spécifiée. De même, si le sous-répertoire source est renommé dans le futur, vos processus de synchronisation arrêteront la mise en miroir des données au moment où l'URL source que vous avez spécifié n'est plus valide.

Le problème, bien sûr, c'est de perdre l'histoire avant le renommage...

Answer 5

J'ai rencontré ce problème et j'ai fini par utiliser svndumpfilter2.

Plus précisément, cette commande :

sudo svnadmin dump /home/setup/svn/repos/main_repl | sudo ./svndumpfilter2.py /home/setup/svn/repos/main_repl Development QA compliance > ~/main_repl_dump.trim

J'ai obtenu l'erreur de mémoire insuffisante mentionnée, cependant, puisque j'exécutais svn sur une VM, j'ai simplement augmenté la mémoire à 2G. Bien que je réalise que ce n'est pas une option pour tout le monde, j'ai remarqué qu'il s'exécutait beaucoup plus rapidement qu'avec 512M. (2G n'était probablement pas nécessaire).

Actuellement, il traite la révision 18.631.

Au cas où quelqu'un se poserait la question, la raison pour laquelle j'ai eu besoin de séparer une partie du repo était que nous créions des tags/copies pour la distribution à l'implémentation de fichiers dans un autre chemin du repo. Pour une raison quelconque, ce processus a fait gonfler le répertoire dans des proportions énormes. (Nous en sommes à 17G maintenant).

Je fais cela sur un dépôt de réplication de SVN, version 1.5.6, sur Debian Lenny, 5.0.4.