Recherche…
Remarques
Cloner de très gros référentiels SVN
Si votre historique de dépôt SVN est vraiment très important, cette opération pourrait prendre des heures, car git-svn a besoin de reconstruire l'historique complet du dépôt SVN. Heureusement, il vous suffit de cloner le dépôt SVN une seule fois. Comme avec tout autre dépôt git, vous pouvez simplement copier le dossier repo sur d'autres collaborateurs. La copie du dossier sur plusieurs ordinateurs sera plus rapide que le simple clonage de gros repos SVN.
A propos des commits et SHA1
Vos commits git locaux seront réécrits lors de l'utilisation de la commande git svn dcommit . Cette commande ajoutera un texte au message de commit git faisant référence à la révision SVN créée dans le serveur SVN, ce qui est très utile. Cependant, l'ajout d'un nouveau texte nécessite de modifier le message d'un commit existant, ce qui ne peut pas réellement être fait: git commits est inmutable. La solution est de créer un nouveau commit avec le même contenu et le nouveau message, mais techniquement c'est un nouveau commit (c’est-à-dire que le SHA1 du commit git changera)
Comme les commits git créés pour git-svn sont locaux, les identifiants SHA1 pour les commits git sont différents entre chaque dépôt git! Cela signifie que vous ne pouvez pas utiliser un SHA1 pour référencer un commit d'une autre personne car le même commit aura un SHA1 différent dans chaque référentiel git local. Vous devez vous appuyer sur le numéro de révision svn ajouté au message de validation lorsque vous transmettez au serveur SVN si vous souhaitez référencer une validation entre différentes copies du référentiel.
Vous pouvez utiliser le SHA1 pour les opérations locales (show / diff un commit spécifique, cerises-picks et resets, etc.)
Dépannage
La commande git svn rebase génère une erreur d'incompatibilité de somme de contrôle
La commande git svn rebase renvoie une erreur similaire à celle-ci:
Checksum mismatch: <path_to_file> <some_kind_of_sha1>
expected: <checksum_number_1>
got: <checksum_number_2>
La solution à ce problème consiste à réinitialiser svn à la révision lorsque le fichier en question a été modifié pour la dernière fois, et à effectuer une extraction git svn pour que l'historique SVN soit restauré. Les commandes pour effectuer la réinitialisation SVN sont:
- git log -1 -
<path_to_file>(copie le numéro de révision SVN qui apparaît dans le message de validation) - git svn reset
<revision_number> - git svn fetch
Vous devriez être capable de pousser / extraire à nouveau les données de SVN
Le fichier n'a pas été trouvé dans commit Lorsque vous essayez d'extraire ou d'extraire SVN, vous obtenez une erreur similaire à celle-ci.
<file_path> was not found in commit <hash>
Cela signifie qu'une révision dans SVN essaie de modifier un fichier qui, pour une raison quelconque, n'existe pas dans votre copie locale. La meilleure façon de se débarrasser de cette erreur est de forcer une extraction en ignorant le chemin de ce fichier et elle sera mise à jour à son état dans la dernière révision SVN:
-
git svn fetch --ignore-paths <file_path>
Cloner le dépôt SVN
Vous devez créer une nouvelle copie locale du référentiel avec la commande
git svn clone SVN_REPO_ROOT_URL [DEST_FOLDER_PATH] -T TRUNK_REPO_PATH -t TAGS_REPO_PATH -b BRANCHES_REPO_PATH
Si votre référentiel SVN suit la disposition standard (tronc, branches, dossiers de balises), vous pouvez économiser de la saisie:
git svn clone -s SVN_REPO_ROOT_URL [DEST_FOLDER_PATH]
git svn clone extrait chaque révision SVN, une par une, et effectue une validation git dans votre référentiel local afin de recréer l'historique. Si le dépôt SVN contient beaucoup de validations, cela prendra du temps.
Lorsque la commande est terminée, vous disposez d'un dépôt git complet avec une branche locale appelée master qui suit la branche du trunk dans le référentiel SVN.
Obtenir les dernières modifications de SVN
L'équivalent de git pull est la commande
git svn rebase
Ceci récupère toutes les modifications du référentiel SVN et les applique sur vos commits locaux dans votre branche actuelle.
Vous pouvez également utiliser la commande
git svn fetch
pour récupérer les modifications du référentiel SVN et les apporter à votre machine locale mais sans les appliquer à votre branche locale.
Modification locale de SVN
La commande
git svn dcommit
créera une révision SVN pour chacun de vos commits git locaux. Comme avec SVN, votre historique de git local doit être synchronisé avec les dernières modifications du référentiel SVN, donc si la commande échoue, essayez d'abord d'effectuer une git svn rebase .
Travailler localement
Utilisez simplement votre dépôt git local comme un référentiel git normal, avec les commandes git normales:
-
git add FILEetgit checkout -- FILEPour mettre en scène / décompresser un fichier -
git commitPour enregistrer vos modifications. Ces commits seront locaux et ne seront pas "poussés" vers le référentiel SVN, comme dans un dépôt git normal. -
git stashetgit stash popPermet d'utiliser des stashes -
git reset HEAD --hardtous vos changements locaux -
git logAccédez à tout l'historique du référentiel -
git rebase -ipour que vous puissiez réécrire votre histoire locale librement -
git branchetgit checkoutpour créer des branches locales
Comme l'indique la documentation de git-svn "Subversion est un système beaucoup moins sophistiqué que Git", vous ne pouvez donc pas utiliser toute la puissance de git sans perturber l'historique du serveur Subversion. Heureusement, les règles sont très simples: gardez l’histoire linéaire
Cela signifie que vous pouvez effectuer presque toutes les opérations git: créer des branches, supprimer / réorganiser / écraser des commits, déplacer l'historique, supprimer des commits, etc. Tout sauf des fusions . Si vous avez besoin de réintégrer l'historique des branches locales, utilisez plutôt git rebase .
Lorsque vous effectuez une fusion, une validation de fusion est créée. La particularité des validations de fusion est qu’elles ont deux parents, ce qui rend l’historique non linéaire. L'historique non linéaire va confondre SVN dans le cas où vous "poussez" une validation de fusion dans le référentiel.
Cependant, ne vous inquiétez pas: vous ne casserez rien si vous "poussez" une validation de git merge sur SVN . Si vous le faites, lorsque la validation git merge est envoyée au serveur svn, elle contiendra toutes les modifications de tous les commits pour cette fusion, vous perdrez ainsi l’historique de ces validations, mais pas les modifications de votre code.
Gestion des dossiers vides
git ne reconnaît pas le concept de dossiers, il ne fait que travailler avec les fichiers et leurs chemins de fichiers. Cela signifie que git ne suit pas les dossiers vides. SVN, cependant. Utiliser git-svn signifie que, par défaut, toute modification apportée à des dossiers vides avec git ne sera pas propagée à SVN .
L'utilisation de l'indicateur --rmdir lors de l'émission d'un commentaire corrige ce problème et supprime un dossier vide dans SVN si vous supprimez localement le dernier fichier qu'il --rmdir :
git svn dcommit --rmdir
Malheureusement, il ne supprime pas les dossiers vides existants : vous devez le faire manuellement.
Pour éviter d'ajouter le drapeau à chaque fois que vous faites un dcommit, ou pour le jouer en toute sécurité si vous utilisez un outil graphique git (comme SourceTree), vous pouvez définir ce comportement par défaut avec la commande:
git config --global svn.rmdir true
Cela modifie votre fichier .gitconfig et ajoute ces lignes:
[svn]
rmdir = true
Pour supprimer tous les fichiers et dossiers non suivis devant rester vides pour SVN, utilisez la commande git:
git clean -fd
Remarque: la commande précédente supprime tous les fichiers non suivis et les dossiers vides, même ceux qui doivent être suivis par SVN! Si vous devez générer des rapports, les dossiers vides suivis par SVN utilisent la commande
git svn mkdirs
En pratique, cela signifie que si vous souhaitez nettoyer votre espace de travail à partir de fichiers et de dossiers non suivis, vous devez toujours utiliser les deux commandes pour recréer les dossiers vides suivis par SVN:
git clean -fd && git svn mkdirs
