Question Comment migrer un référentiel SVN avec l'historique vers un nouveau référentiel Git?


J'ai lu le manuel de Git, la FAQ, le cours accéléré de Git - SVN, etc. et ils ont tous expliqué ceci et cela, mais vous ne trouverez nulle part une instruction simple comme:

SVN référentiel dans: svn://myserver/path/to/svn/repos

Git repository dans: git://myserver/path/to/git/repos

git-do-the-magic-svn-import-with-history \
svn://myserver/path/to/svn/repos \
git://myserver/path/to/git/repos

Je ne m'attends pas à ce que ce soit aussi simple, et je ne m'attends pas à ce que ce soit une seule commande. Mais je m'attends à ne pas essayer d'expliquer quoi que ce soit - juste pour dire quelles sont les mesures à prendre étant donné cet exemple.


1392
2017-09-17 02:08


origine


Réponses:


La magie:

$ git svn clone http://svn/repo/here/trunk

Git et SVN fonctionnent très différemment. Vous devez apprendre Git, et si vous voulez suivre les changements de SVN en amont, vous devez apprendre git-svn. le git-svn page de manuel a une bonne section d'exemples:

$ git svn --help

495
2017-09-17 18:20



Créez un fichier d'utilisateurs (c.-à-d. users.txt) pour mapper les utilisateurs SVN à Git:

user1 = First Last Name <email@address.com>
user2 = First Last Name <email@address.com>
...

Vous pouvez utiliser ce one-liner pour créer un modèle à partir de votre référentiel SVN existant:

svn log -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > users.txt

SVN s'arrêtera s'il trouve un utilisateur SVN manquant ne figurant pas dans le fichier. Mais après cela, vous pouvez mettre à jour le fichier et reprendre là où vous vous étiez arrêté.

Maintenant, tirez les données SVN du dépôt:

git svn clone --stdlayout --no-metadata --authors-file=users.txt svn://hostname/path dest_dir-tmp

Cette commande créera un nouveau dépôt Git dans dest_dir-tmp et commencez à tirer le dépôt SVN. Notez que le drapeau "--stdlayout" implique que vous avez la disposition commune "trunk /, branches /, tags /" SVN. Si votre mise en page diffère, familiarisez-vous avec --tags, --branches, --trunk options (en général git svn help).

Tous les protocoles courants sont autorisés: svn://, http://, https://. L'URL doit cibler le référentiel de base, quelque chose comme http://svn.mycompany.com/myrepo/repository. Ça doit ne pas comprendre /trunk, /tag ou /branches.

Notez qu'après l'exécution de cette commande, il semble très souvent que l'opération est "suspendue / figée", et il est tout à fait normal qu'elle puisse être bloquée longtemps après l'initialisation du nouveau référentiel. Finalement, vous verrez alors les messages de log qui indiquent qu'il migre.

Notez également que si vous omettez le --no-metadata flag, Git ajoutera des informations sur la révision SVN correspondante au message de validation (c.-à-d. git-svn-id: svn://svn.mycompany.com/myrepo/<branchname/trunk>@<RevisionNumber> <Repository UUID>)

Si un nom d'utilisateur n'est pas trouvé, mettez à jour votre users.txt fichier alors:

cd dest_dir-tmp
git svn fetch

Vous devrez peut-être répéter cette dernière commande plusieurs fois, si vous avez un projet volumineux, jusqu'à ce que toutes les validations Subversion aient été récupérées:

git svn fetch

Une fois terminé, Git va vérifier le SVN trunk dans une nouvelle branche. Toutes les autres branches sont configurées en tant que télécommandes. Vous pouvez voir les autres branches SVN avec:

git branch -r

Si vous souhaitez conserver d'autres branches distantes dans votre référentiel, vous devez créer une branche locale pour chacune d'entre elles manuellement. (Ignorer le coffre / maître.) Si vous ne le faites pas, les branches ne seront pas clonées dans l'étape finale.

git checkout -b local_branch remote_branch
# It's OK if local_branch and remote_branch are the same name

Les tags sont importés en tant que branches. Vous devez créer une branche locale, créer une étiquette et supprimer la branche pour les avoir comme balises dans Git. Pour le faire avec le tag "v1":

git checkout -b tag_v1 remotes/tags/v1
git checkout master
git tag v1 tag_v1
git branch -D tag_v1

Clonez votre référentiel GIT-SVN dans un référentiel Git propre:

git clone dest_dir-tmp dest_dir
rm -rf dest_dir-tmp
cd dest_dir

Les branches locales que vous avez créées précédemment à partir de branches distantes ont uniquement été copiées en tant que branches distantes dans le nouveau référentiel cloné. (Ignorer le coffre / maître.) Pour chaque branche que vous souhaitez conserver:

git checkout -b local_branch origin/remote_branch

Enfin, supprimez la télécommande de votre référentiel Git propre qui pointe vers le référentiel temporaire désormais supprimé:

git remote rm origin

1466
2017-09-17 17:09



Migrez proprement votre référentiel Subversion vers un référentiel Git. Vous devez d'abord créer un fichier qui mappe vos noms d'auteur de commit Subversion aux commit Git, disons ~/authors.txt:

jmaddox = Jon Maddox <jon@gmail.com>
bigpappa = Brian Biggs <bigpappa@gmail.com>

Ensuite, vous pouvez télécharger les données Subversion dans un dépôt Git:

mkdir repo && cd repo
git svn init http://subversion/repo --no-metadata
git config svn.authorsfile ~/authors.txt
git svn fetch

Si vous êtes sur un Mac, vous pouvez obtenir git-svn de MacPorts en installant git-core +svn.

Si votre référentiel subversion est sur la même machine que votre référentiel git, alors vous pouvez utiliser cette syntaxe pour l'étape init, sinon tout de même:

git svn init file:///home/user/repoName --no-metadata

183
2017-09-21 02:15



J'ai utilisé le script svn2git et fonctionne comme un charme! https://github.com/nirvdrum/svn2git


67
2017-09-26 13:13



Je suggère de me familiariser avec Git avant d'essayer d'utiliser git-svn en permanence, c'est-à-dire en gardant SVN comme repo centralisé et en utilisant Git localement.

Cependant, pour une simple migration avec tout l'historique, voici les quelques étapes simples:

Initialiser le repo local:

mkdir project
cd project
git svn init http://svn.url

Indiquez jusqu'où vous voulez commencer à importer les révisions:

git svn fetch -r42

(ou juste "git svn fetch" pour tous les revs)

En fait, aller chercher tout depuis:

git svn rebase

Vous pouvez vérifier le résultat de l'importation avec Gitk. Je ne suis pas sûr que cela fonctionne sur Windows, cela fonctionne sur OSX et Linux:

gitk

Lorsque vous avez cloné votre dépôt SVN localement, vous pouvez le pousser vers un dépôt Git centralisé pour faciliter la collaboration.

Créez d'abord votre repo distant vide (peut-être sur GitHub?):

git remote add origin git@github.com:user/project-name.git

Puis, optionnellement, synchronisez votre branche principale afin que l'opération de fusion fusionne automatiquement le maître distant avec votre maître local, lorsque les deux contiennent de nouveaux éléments:

git config branch.master.remote origin
git config branch.master.merge refs/heads/master

Après cela, vous pourriez être intéressé à essayer ma propre git_remote_branch outil, qui aide à gérer les branches distantes:

Premier message explicatif: "Git branches distantes"

Suivi de la version la plus récente: "Il est temps de collaborer avec git_remote_branch"


56



Il existe une nouvelle solution pour une migration en douceur de Subversion vers Git (ou pour utiliser les deux simultanément): SubGit (http://subgit.com/).

Je travaille sur ce projet moi-même. Nous utilisons SubGit dans nos dépôts - certains de mes coéquipiers utilisent Git et certains Subversion et jusqu'à présent cela fonctionne très bien.

Pour migrer de Subversion vers Git avec SubGit, vous devez exécuter:

$ subgit install svn_repos
...
TRANSLATION SUCCESSFUL 

Après cela, vous aurez le dépôt Git dans svn_repos / .git et vous pourrez le cloner, ou simplement continuer à utiliser Subversion et ce nouveau dépôt Git ensemble: SubGit s'assurera que les deux sont toujours synchronisés.

Si votre référentiel Subversion contient plusieurs projets, plusieurs référentiels Git seront créés dans le répertoire svn_repos / git. Pour personnaliser la traduction avant de l'exécuter, procédez comme suit:

$ subgit configure svn_repos
$ edit svn_repos/conf/subgit.conf (change mapping, add authors mapping, etc)
$ subgit install svn_repos

Avec SubGit vous pouvez migrer vers Git pur (pas git-svn) et commencer à l'utiliser tout en conservant Subversion aussi longtemps que vous en avez besoin (pour vos outils de construction déjà configurés, par exemple).

J'espère que cela t'aides!


29



Voir le fonctionnaire git-svn page de manuel. En particulier, regardez sous "Exemples de base":

Suivi et contribution à l'ensemble d'un projet géré par Subversion (complet       avec un coffre, des étiquettes et des branches):

# Clone a repo (like git clone):
    git svn clone http://svn.foo.org/project -T trunk -b branches -t tags

16



Pro Git 8.2 l'explique: http://git-scm.com/book/fr/Git-and-Other-Systems-Migrating-to-Git


14



SubGit (vs écran bleu de la mort)

subgit import --svn-url url://svn.serv/Bla/Bla  directory/path/Local.git.Repo

C'est tout.

+ Pour mettre à jour à partir de SVN, un référentiel Git créé par la première commande.

subgit import  directory/path/Local.git.Repo

J'ai utilisé un moyen de migrer vers Git instantanément pour un énorme dépôt.
Bien sûr, vous avez besoin de préparation.
Mais vous ne pouvez pas arrêter le processus de développement, du tout.

Voici mon chemin.

Ma solution ressemble à:

  • Migrer SVN vers un dépôt Git
  • Mettre à jour le référentiel Git juste avant que l'équipe passe à.

La migration prend beaucoup de temps pour un grand dépôt SVN.
Mais mise à jour de la migration terminée en quelques secondes.

Bien sûr que j'utilise SubGit, maman. git-svn me fait Écran bleu de la mort. Juste constamment. Et git-svn m'ennuie avec Git's "nom de fichier trop long" erreur fatale.

PAS

1.  Télécharger SubGit

2. Préparez la migration et la mise à jour des commandes.

Disons que nous le faisons pour Windows (il est trivial de le porter sur Linux).
Dans l'installation d'un SubGit poubelle directory (subgit-2.X.X \ bin), crée deux fichiers .bat.

Contenu d'un fichier / commande pour la migration:

start    subgit import --svn-url url://svn.serv/Bla/Bla  directory/path/Local.git.Repo

La commande "start" est facultative ici (Windows). Cela permettra de voir les erreurs au démarrage et laissera un shell ouvert après la fin du SubGit.

Vous pouvez ajouter ici paramètres supplémentaires similaires à git-svn. J'utilise seulement --default-domain myCompanyDomain.com réparer le domaine de l'adresse email des auteurs SVN.
J'ai la structure du référentiel SVN standard (trunk / branches / tags) et nous n'avons pas eu de problèmes avec "authors mapping". Donc je ne fais plus rien.

(Si vous voulez migrer des tags comme des branches ou si votre SVN a plusieurs dossiers de branches / tags, vous pouvez envisager d'utiliser le SubGit plus détaillé approche)

Astuce 1: Utilisez --minimal-revision YourSvnRevNumber pour voir rapidement comment les choses se terminent (une sorte de débogage). Particulièrement utile est de voir les noms d'auteurs résolus ou des email.
Ou pour limiter la profondeur de l'historique de migration.

Astuce 2: La migration peut être interrompue (Ctrl + C) et restauré en exécutant la prochaine commande / fichier de mise à jour.
Je ne conseille pas de faire cela pour les grands dépôts. J'ai reçu "Exception Java + Windows hors mémoire".

Astuce 3: Mieux vaut créer une copie de votre référentiel nu.

Contenu d'un fichier / commande pour la mise à jour:

start    subgit import  directory/path/Local.git.Repo

Vous pouvez l'exécuter n'importe quel nombre de fois lorsque vous souhaitez obtenir les validations de la dernière équipe dans votre référentiel Git.

Attention! Ne touchez pas votre dépôt nu (création de branches par exemple).
Vous allez prendre la prochaine erreur fatale:

Erreur irrécupérable: ne sont pas synchronisés et ne peuvent pas être synchronisés ... La traduction des révisions de Subversion en commit Git ...

3. Exécutez la première commande / fichier. Ça va prendre beaucoup de temps pour un grand dépôt. 30 heures pour mon humble référentiel.

C'est tout.
Vous pouvez mettre à jour votre référentiel Git à partir de SVN à n'importe quel moment, en exécutant le second fichier / commande. Et avant de passer de votre équipe de développement à Git.
Cela ne prendra que quelques secondes.



Il y a une tâche plus utile.

Poussez votre référentiel Git local vers un référentiel Git distant

Est-ce votre cas? Continuons.

  1. Configurez vos télécommandes

Courir:

$ git remote add origin url://your/repo.git
  1. Préparez l'envoi initial de votre énorme référentiel Git local vers un référentiel distant

Par défaut, votre Git ne peut pas envoyer de gros morceaux. fatale: L'extrémité distante a raccroché de façon inattendue

Courons pour cela:

git config --global http.postBuffer 1073741824

524288000 - 500 Mo 1073741824 - 1 Go, etc.

Fixez votre local problèmes de certificat. Si votre serveur git utilise un certificat cassé.

J'ai désactivé certificats.

De plus, votre serveur Git peut avoir un demandes de limites de quantité devant être corrigées.

  1. Poussez toute la migration dans le dépôt Git distant de l'équipe.

Exécuter avec un Git local:

git push origin --mirror

(git push origine '*: *' pour les anciennes versions de Git)

Si vous obtenez ce qui suit: erreur: impossible de générer git: aucun fichier ou répertoire de ce type... Pour moi, la recréation complète de mon référentiel résout cette erreur (30 heures). Vous pouvez essayer les prochaines commandes

git push origin --all
git push origin --tags

Ou essayez de réinstaller Git (inutile pour moi). Ou vous pouvez créer des branches à partir de toutes vos étiquettes et les pousser. Ou, ou, ou ...


12



reposurgeon

Pour les cas compliqués, repasser par Eric S. Raymond est l'outil de choix. En plus de SVN, il prend en charge de nombreux autres systèmes de contrôle de version via le fast-export format, et aussi CVS. L'auteur rapporte des conversions réussies de dépôts anciens tels que Emacs et FreeBSD.

L'outil apparemment vise à une conversion presque parfaite (comme la conversion de SVN svn:ignore propriétés à .gitignore fichiers) même pour les mises en page de référentiel difficiles avec une longue histoire. Dans de nombreux cas, d'autres outils peuvent être plus faciles à utiliser.

Avant de plonger dans la documentation du reposurgeon ligne de commande, assurez-vous de lire l'excellent Guide de migration DVCS qui va sur le processus de conversion, étape par étape.


8