11
votes

Travailler localement avec git quand le référentiel principal est SVN

Il y a un projet open source que je veux vérifier et contribuer à. Le référentiel principal est SVN mais je veux travailler dans Git. Est-ce possible?

La plupart de mes recherches augmentent les guides où vous passez de SVN à Git (ou l'inverse autour) et ne regarde pas en arrière.

  • Si je vérifie le projet, effectuez une modification et poussez-la à la branche que j'ai créée sur GitHub, comment dois-je notifier les auteurs originaux?
  • Quelle est la force d'inclure une contribution faite sur un repos git dans un repos de svn?
  • Il suffit de comparer deux révisions (ma dernière caisse / pull / update et mon propre commit local), générez un patch de celui-ci et de les envoyer; Devrait-il être considéré comme un flux de travail de secours ou est l'approche standard?

    suppose que les auteurs originaux n'ont aucun intérêt dans l'apprentissage autre que SVN.

    [MISE À JOUR] Je n'ai pas, je ne veux pas non plus avoir, commettre l'accès au référentiel SVN. Je cherche des solutions de contournement pour cela.

    [update2] Si les correctifs sont bien ma seule option, y a-t-il des mises en garde supplémentaires que je devrais être au courant?


0 commentaires

4 Réponses :


3
votes

Oui! C'est possible!

Vérifiez cet article pour les détails: http://www.romanenco.com/gitsvn < / p>

Il y a trois ou quatre étapes simples pour faire de la symbiose de SVN et SCMS GIT.

J'ai travaillé avec cette technologie d'environ trois mois et n'a aucun problème. C'est vraiment cool! Lorsque votre repo principal dans le SVN et que vous pouvez faire des commits hors ligne et obtenir un puissant de la fusion GIT.


0 commentaires

7
votes

Heureusement, il y a git-svn dans ce but précis. Il vous permet d'utiliser git localement tout en étant en mesure de vérifier à SVN lorsque vous souhaitez le faire. Il est assez simple et il y a beaucoup d'informations si vous recherchez git-svn ici ou via Google.

Il y a un tutoriel http://flavio.castelli.name/howto_use_git_with_svn que vous voudrez peut-être à regarder d'abord.

Modifier Pour générer diffs compatibles SVN vous pouvez utiliser git diff --no-prefix . A noter toutefois que ce format n'est pas compatible avec TortoiseSVN. Si la compatibilité est nécessaire, vous devez utiliser une sorte de script shell; voir par exemple ici: http://mojodna.net/2009/ 02/24 / mon travail-git-workflow.html

Modifier Un inconvénient potentiel de git-svn est qu'il ne gère pas svn externals. Vous devrez gérer vous-même les.

Bonne chance!


2 commentaires

Oui, j'ai regardé certains à Git-Svn. Il a fière allure d'aller chercher les mises à jour des repos originaux (SVN). Mais je suis principalement intéressé par le flux de travail en amont. Comment bien gérer et générer correctement les patchs (si c'est ma seule option)?


J'ai maintenant inclus des informations sur la génération de correctifs SVN dans ma réponse.



7
votes

Garder un référentiel git en synchronisée avec un référentiel Subversion est vraiment simple:

clone le référentiel de subversion (dans cet exemple simple, je ignore les branches / balises) p> xxx pré>

Continuez à jour avec le tronc de subversion: P>

$ git diff 1cc92b96 > my_patch.patch


1 commentaires

Pourquoi ne devrais-je pas faire commettre la succursale de synchronisation? Seulement parce que c'est plus facile de générer le diff (étant donné que je n'ai que besoin d'un identifiant de validation)?



1
votes

Si vous ne possédez pas, vous ne souhaitez pas non plus avoir accès au référentiel SVN, puis une combinaison de git-svn code> et stgit pourrait aider. git-svn code> crée / mises à jour un clone et stg code> gère une série de correctifs ( stg code> provenant de STGIT CLAST COURS ):

git svn clone ..

stg new invent-some-patch-id
...edit patch description...
...hack hack hack in the tree...
stg refresh
...possibly hack some more...
stg refresh    
..
stg mail


1 commentaires

Intéressant, merci, je vais vérifier le stgit quand je rentre à la maison. En fait, je pense que le plus gros problème ici est d'essayer de travailler avec des personnes qui ne croient pas aux systèmes de contrôle de la version distribués. Mais ils sont juste pour manipuler manuellement des correctifs de toute façon, donc je me rends de plus en plus que c'est probablement la voie à suivre.