Question Accélérer la récupération initiale de git-svn


J'ai un grand dépôt, plus de 100 000 révisions avec un facteur de branchement très élevé. La récupération initiale du dépôt SVN complet à l'aide de git-svn a duré environ 2 mois et sa révision est limitée à 60 000. Est-il possible d'accélérer cette chose?

Je suis déjà en train de tuer et de redémarrer régulièrement le fetch à cause de la fuite de mémoire de git-svn comme un tamis. Le transfert a lieu sur le LAN local, la vitesse de la liaison ne devrait donc pas être un problème. Le référentiel se trouve sur une machine dédiée soutenue par des baies Fibre Channel dédiées, de sorte que le serveur doit avoir beaucoup de possibilités. La seule autre chose à laquelle je peux penser est de faire le clone depuis une copie locale du référentiel SVN.

Qu'ont fait les autres dans des circonstances similaires?


35
2017-10-13 00:11


origine


Réponses:


Au travail, j'utilise git-svn contre un référentiel SVN de révision ~ 170000. Ce que j'ai fait était d'utiliser git-svn init + git-svn fetch -r... limiter mon extraction initiale à un nombre raisonnable de révisions. Vous devez faire attention à choisir une révision qui se trouve dans la branche de votre choix. Tout est entièrement fonctionnel même avec une histoire tronquée sauf  git-blame, qui attribue évidemment toutes les lignes plus anciennes que votre version initiale à la première.

Vous pouvez accélérer cela avec ignore-path pour éliminer les sous-arbres que vous ne voulez pas.

Vous pouvez ajouter plus de révisions plus tard, mais ce sera douloureux. Vous devrez réinitialiser le rev-map (malheureusement, j'ai même écrit git-svn reset et je ne peux pas dire de manière désinvolte si cela enlèvera tout révisions, donc il peut être à la main). alors git-svn fetch plus de révisions et git-filter-branch pour réparer votre ancienne racine sur le nouvel arbre. Cela réécrira chaque commit mais cela n'affectera pas les blobs sources eux-mêmes. Vous devez faire une opération similaire lorsque les gens entreprennent de grandes réorganisations du svn repo.

Si vous avez réellement besoin tout des révisions (par exemple pour une migration), vous devriez alors regarder quelques exemples de svn-fast-export + git-fast-import. Il y en a peut-être un qui ajoute des balises rev à git-svn, auquel cas vous pouvez importer rapidement et ensuite simplement greffer dans la télécommande svn. Même si les options existantes de svn-fast-export n'ont pas cette fonctionnalité, vous pouvez probablement l'ajouter avant la fin de votre clone d'origine!


19
2017-10-20 03:35



Apparemment, il n'y a pas de bonne réponse. Certains travaux sont en cours sur git-fast-import, mais ils ne sont pas encore prêts pour le prime time. Ils essaient toujours de comprendre comment détecter et représenter les actions svn cp. Le seul point positif est que quelqu'un sur la liste a proposé une optimisation pour git-svn qui semble avoir eu un grand impact.

http://permalink.gmane.org/gmane.comp.version-control.git/168718


12
2018-03-22 06:29



Dans un dépôt contenant 20 000 commits, j'avais des problèmes similaires. Dans mon cas, il s'est avéré qu'il y avait quelques étiquettes étranges dans Subversion qui ont causé des problèmes. Il y avait des balises qui copiaient / à la place de / trunk. Git svn va chercher en boucle infinie. Je l'ai corrigé en convertissant des morceaux.

git svn fetch -r0:1000
git svn fetch -r0:2000
git svn fetch -r0:3000

Regardez la sortie et si vous ne voyez pas de nouveau r ... de temps en temps, quelque chose ne va pas. Utilisation git log --allpour voir jusqu'où la conversion a eu. Disons que vous êtes arrivé à 1565. Puis continuez comme ça.

git svn fetch -r1567:2000

C'était très fastidieux mais ça a fait le travail.


3
2018-03-20 10:24



Si vous pouvez trouver un serveur avec suffisamment de RAM, effectuez l'opération de clonage complète sur un disque virtuel. Sur les systèmes Linux, vous pouvez utiliser / dev / shm, qui est soutenu par la RAM.

> svnadmin hotcopy /path/to/svn/repo /dev/shm/svn-repo

> git svn clone file:///dev/shm/svn-repo /dev/shm/git-repo

Une fois cela fait, vous pouvez rediriger le repo git vers votre vrai svn repo, comme décrit ici: https://git.wiki.kernel.org/index.php/GitSvnSwitch

  • Modifiez l'URL de l'URL svn-remote dans .git / config pour pointer vers le nouveau nom de domaine
  • Exécuter git svn fetch - Ceci doit récupérer au moins une nouvelle révision de svn!
  • Remplacez l'URL svn-remote par l'URL d'origine
  • Exécutez git svn rebase -l pour effectuer un rebase local (avec les modifications apportées lors de la dernière opération de récupération)
  • Changer l'URL svn-remote à la nouvelle URL
  • Exécuter git svn rebase devrait maintenant fonctionner à nouveau!

Cela ne fonctionnera que si l'étape de récupération de git svn récupère réellement n'importe quoi! (Il m'a fallu du temps pour découvrir cela ... J'ai dû mettre une révision factice dans notre dépôt svn pour que ça arrive!)

Je viens de le faire et j'ai pu cloner un svn repo de révision 4.7G 12000 en 3 heures environ.


2
2017-08-19 03:54



Je pense que tu es sur la bonne voie

L'accès aux fichiers locaux pourrait vous donner une accélération de l'ordre de 1 à 2.

Je ne suis pas certain que lancer git svn sur un bdb ou un fichier basé sur svn serait plus rapide.


1
2017-10-13 00:41



J'ai déjà téléchargé un dépôt SVN de près de 100 000 révisions avec git-svn auparavant. Il a fallu environ 48 heures et était ne pas sur un LAN local. Certes, vous avez bien dit que votre dépôt a un facteur de branchement élevé, alors que le dépôt que j'ai téléchargé ne l’avait pas (bien qu’il contienne plusieurs dizaines de branches)

Je suggère de travailler à déterminer où se situe le goulot d'étranglement. Est-ce que git-svn et ses sous-processus utilisent 100% du processeur? Les voyants du disque ou du serveur SVN sont-ils allumés en permanence? Combien de bande passante est utilisée? Une fois que vous savez quel est le facteur limitant, vous pouvez essayer de trouver une solution.


1
2017-10-13 18:56



Je suis en train de migrer un référentiel de révision de 45k et je trouve git-svn sous Linux environ 10 fois plus rapide que git-svn sur ma fenêtre Windows. Le vm est sur le même HyperV que mon svn repo donc ça pourrait être ça.


0
2018-04-24 08:26



J'ai un repo avec des critiques 8k + et environ 240 tags. J'ai essayé de courir et a estimé que mon clone inti de git svn sur Windows aurait pris des mois, faisant simplement

git svn clone --stdlayout --no-metadata --authors-file=users.txt https://link.to.repo

Le clone prenait 5 secondes pour importer 1 révision en moyenne. Veuillez noter que chaque fois qu'une balise est rencontrée, le clone redémarre à partir de rev 1, il y a donc potentiellement 8 000 * 240 opérations = 111 jours.

Résumé de toutes mes démarches pour accélérer le processus:

  1. L'implémentation de linux et osx est beaucoup plus rapide que cygwin sur Windows. J'ai utilisé une machine virtuelle Linux. Vérifiez s'il vous plaît https://stackoverflow.com/a/21599759/1448276

  2. J'ai copié la totalité du dépôt svn sur ma machine avec svnrdump

svnrdump dump https://link.to.repo > repos.dump

  1. J'ai créé un svn repo local

    svnadmin create svnrepo

    svnadmin load svnrepo < repos.dump

un péché https://stackoverflow.com/a/10407464/1448276 

  1. J'ai créé et monté un disque RAM

    svnadmin hotcopy svnrepo/ /dev/shm/svnrepo

comme ci-dessus, https://stackoverflow.com/a/39030862/1448276

  1. Et finalement couru le clone

    git svn clone --stdlayout --no-metadata --prefix=origin/ --authors-file=users.txt file:///dev/shm/svnrepo

Ici, le clone traite en moyenne 12,5 révisions par seconde, donc je pense qu'il faudra moins de 2 jours. Je posterai une mise à jour une fois le clone terminé.


0
2017-09-13 07:32