Différents clones peuvent svn-git du même référentiel svn attendent de pouvoir partager les modifications puis git svn dcommit?

Question

J'ai lu beaucoup de « passer de svn à git » et d'autres articles « de workflow git-svn » sur le web, et encore je pense qu'ils traitent souvent des situations trop simples. Ils sont souvent ciblés sur les gars qui veulent juste utiliser git et pirater localement, sans utiliser la pleine puissance de git, comme pull, chercher, fusionner et similaires entre plusieurs développeurs qui ont tous cloné le dépôt svn avec git-svn, puis attendre toujours être en mesure de pousser leurs changements tout temps au dépôt svn (officiel), et de se remettre à travailler dans git et de partager leurs trucs etc.

Chaque fois que ces articles admettent que vous ne pouvez pas faire tout ce que vous feriez dans git pur, les conséquences et les hauts vis possibles ne sont jamais clairement expliquées (ou peut-être juste moi?). Même la page man git-svn mentionne des mises en garde, mais pas vraiment de manière extensive.

D'après ce que je l'ai lu, je me sens qu'il pourrait y avoir des problèmes lors de cette façon spécifique est utilisé git-svn, que je vais décrire ci-dessous. Quelqu'un peut-il me dire si je ne me trompe pas à ce sujet?

Voici le chemin « voulait » de faire les choses:

1. Nous avons un projet dans un dépôt svn
2. Développeur A-clone git-svn est le repo svn. Il commence à pirater les choses sur place
3. Développeur B git-svn-clone est le même repo svn. Il commence à pirater les choses lui-même.
4. Après avoir fait cela pendant un certain temps, peut-être ajouter devs C / D / ..., et ayant d'autres développeurs qui font « standard » svn engage à la prise en pension d'origine, les utilisateurs git voudrait partager leur code et faire toutes sortes de la magie git.
5. Tout un de ces utilisateurs git aimerait pouvoir pousser les changements maintenant fusionné à svn (dcommit?)

Ma question est: suis-je en train de rêver? J'ai lu il y a quelque temps, dans un livre git Je pense que clone git-svn pourrait créer des dépôts git qui sont bien sûr un « miroir » du repo svn, mais que repo git créé de cette façon par les différents développeurs auraient différents " ids » et commits auraient différentes hash. Donc, je crois comprendre que ces mises en pension git ne partageait aucune ancêtre git commun, et ne serait donc pas en mesure d'utiliser toutes les commandes git dont vous avez besoin de partager, fusionner, et ainsi de suite. Est-il vrai, allons-nous faire face à des problèmes avec ce flux de travail?

Parfois, je lis cela pourrait se faire, en utilisant au moins un dépôt git nue « officielle », ce serait le seul à être git-svn-clonés, et tous les utilisateurs git devrait commencer sous forme celui-ci. Ensuite, vous avez besoin de quelqu'un qui est en charge de ce git central, et rassemble les changements entre les devs git, avant tout dcommiting au repo svn. Ce serait la seule façon pour les utilisateurs git d'être « pas au courant » que le git d'origine provient de svn, et laisserait les utiliser toutes les commandes git comme ils aiment. La seule personne qui aurait besoin d'être à l'aise dans les deux git et svn (et connaître des mises en garde git-svn) serait le « gestionnaire de fusion » (ou ce qu'il appelle).

Suis-je mises en garde git-svn complètement malentendu? Y at-il plus simple de le faire?

Answer 1

Le problème est l'étape 4 bien sûr. Un dcommit tente de rejouer votre histoire locale au serveur. Dcommit prétend que vous êtes un client SVN. Maintenant, si le code que vous dcommitting est non seulement de vous, c'est quelque chose qui est difficile à dcommit à SVN.

Voici ce que le écrit sur la question:

  

  
• Par souci de simplicité et interopérer avec SVN, il est   recommandé que tous les utilisateurs git-svn   clone, chercher et dcommit directement à partir de   le serveur SVN (SVN distant   dépôt qui est), et éviter tout   git-clone / pull / fusion / push opérations   entre les dépôts git et les branches   qui sont soit récupérées via git svn   clone et qui sont également utilisés pour pousser   changesets Rentrant dans la SVN à distance   dépôt.
  
• La méthode recommandée d'échange de code entre les branches git   et les utilisateurs est le format-patch git et git   je suis, ou tout simplement git svn dcommit au SVN   dépôt.
  
• Depuis dcommit git svn utilise rebasage git svn interne, toutes les branches git nous   git push avant de svn git sur dcommit   il faudra les forcer un écrasement   de l'arbitre existant sur la télécommande   dépôt. Ceci est généralement   considéré comme une mauvaise pratique, voir le   documentation git push pour plus de détails.
  
• Running fusion ou git git pull n'est pas recommandé sur une branche, nous prévoyons   git svn dcommit de. SVN ne   représentent des fusions en tout ou raisonnable   la mode utile afin que les utilisateurs en utilisant SVN   ne peut pas voir des fusions que nous avons fait.   De plus, si l'on git fusionner ou git   tirer d'une branche git qui est   miroir d'une branche SVN, git svn   dcommit peut commettre à la mauvaise   branche.
  
• clone git ne clone pas de branches sous le refs / remotes / ou hiérarchie   les métadonnées git-svn ou config. Alors   référentiels créé et géré avec   en utilisant git-svn devrait utiliser rsync   pour le clonage, si le clonage est à faire   du tout.
  
• Il ne faut pas utiliser l'option de --amend git commit sur un changement que nous   ont déjà dcommitted. Il est   considéré comme une mauvaise pratique --amend   commits nous avons déjà poussé à une   dépôt distant pour les autres utilisateurs, et   dcommit avec SVN est analogue à celui.   Plus d'informations sur ce qui peut être trouvé   à modifier un engagement et    avec réécriture historique.
  

Answer 2

J'ai expérimenté beaucoup de choses avec ce ces derniers temps, et je pense que j'ai réussi à trouver une configuration qui fonctionne un peu. Oui, il est un régime strict de rebasage seule, oui il est compliqué, mais on en utiliser Git pour travailler localement (vitesse, histoire, Stash, index, etc).

Vous pouvez utiliser des branches dans les coulisses lorsque vous travaillez en équipe avec d'autres utilisateurs Git dans votre équipe, je pense, mais n'ont pas personnellement trop expérimenté cela. Tant que vous linéariser le journal avant dcommitting il devrait fonctionner.

Voici la version courte (répète beaucoup ce qui a été déjà dit):

1. Cloner le repo Subversion dans une "récupération" repo sur un serveur central
2. Init un repo "nu" sur le même serveur
3. Push de la prise en pension fecthing à la prise en pension nue
4. Demandez aux développeurs de cloner le repo nu, puis
   5. git svn init svnurl pour configurer la télécommande git-svn, et
   6. git update-ref refs/remotes/git-svn refs/remotes/origin/master donc git-svn a un pointeur vers une révision
5. automatiquement (validation crochet) ont le "aller chercher" repo svn rebasage, et pousser à la mise en pension nue
6. Les développeurs tirent du repo nu avec git pull --rebase
7. Les développeurs git svn dcommit en cours d'exécution d'abord répéter le update-ref ci-dessus en cas de nouvelles révisions à venir de SVN.

Il y a une illustration du flux de travail sur cette page (j'ai besoin plus de points de réputation avant que je puisse inline l'image). Mise à jour: nous allons ici:

Answer 3

Ce que je faisais, est de créer un clone git initial svn, puis partagé il .git parmi les développeurs utilisant git, donc nous avons eu exactement les mêmes références.
Il semblait fonctionner correctement que nous avons pu utiliser « caractéristiques spécifiques git » entre les utilisateurs git, aussi longtemps que nous sommes restés dans un arbre linéaire (c.-à-rebasage au lieu de la fusion).

Answer 4

Dès que vous entrez en cause « distribuée », vous êtes mieux avec un git nu cloné parmi les développeurs.
En ce qui concerne la phase d'import-export à la prise en pension SVN public pour les autres à utiliser, les scripts
git2svn et svn2git peut aider encapsulent la magie.

D'autres considérations lorsque vous travaillez dans repo Git et SVN se trouvent dans la question

Answer 5

Il y a un outil qui permet de résoudre le problème du partage dépôt Git synchronisé avec dépôt Subversion.

SubGit est un miroir côté serveur bidirectionnel Git-SVN.

On peut installer SubGit dans un dépôt Subversion et obtenir dépôt Git automatiquement synchronisé avec SVN:

$ subgit configure $SVN_REPOS
# Adjust $SVN_REPOS/conf/subgit.conf to specify branches, tags and other options;
# Adjust $SVN_REPOS/conf/authors.txt to specify git & svn authors mapping
$ subgit install $SVN_REPOS
...
$ INSTALLATION SUCCESSFUL

SubGit installe avant et engager des crochets en post-commit dépôt Subversion, avant de recevoir et de post-recevoir des crochets en dépôt Git. En conséquence, il se traduit immédiatement par des modifications entrantes de côtés SVN et Git. Après les développeurs d'installation de SubGit peuvent utiliser un client Git pour cloner et travailler avec dépôt Git.

SubGit ne repose pas sur git-svn, il utilise son propre moteur de traduction notre équipe a développé. Plus de détails sur ce vous pouvez trouver SubGit vs git-svn comparaison. Documentation générale sur les SubGit est disponible .

La version 1.0 de SubGit a besoin d'un accès local au référentiel Subversion, à savoir les dépôts SVN et Git doivent résider sur le même hôte. Mais avec la version 2.0, nous allons introduire le mode proxy Git, lorsque les dépôts Subversion et Git peuvent se trouver partout et que les dépôts Git ont SubGit installés en eux, à savoir les dépôts Subversion restent intactes.

SubGit est un produit commercial. Il est gratuit pour open-source, projet académique ainsi que des projets jusqu'à 10 committers.

Disclaimer: Je suis l'un des développeurs de SubGit

.

Answer 6

J'ai trouvé ce billet de blog qui suggère en gardant une branche distincte pour la synchronisation avec le dépôt Subversion, de sorte qu'il sera toujours possible de faire pousser / tirer dans la branche principale.

Answer 7

L'un des problèmes que je perçois avec git-svn est qu'il stocke l'id-git-svn dans le commit commentaire; parce que ce récrit qui commettent, il change, il est SHA1, donc vous ne pouvez pas pousser partout où les gens seront partager.

Je préfère en fait bzr-svn parce qu'au lieu il stocke les revid bzr dans la révision SVN à distance en utilisant les propriétés de révision SVN fonction au lieu qui signifie pas de réécriture de révision locale. Il a également la propriété désirée, que deux tractions indépendants de la même branche SVN se traduira par des branches bzr identiques et interopérables.