Comment rendre un DVCS totalement interopérable avec Subversion?

Question

Quels changements architecturaux un DVCS devrait-il être complètement interopérable avec Subversion?

De nombreux DVCS ont une sorte d'interface bidirectionnelle avec Subversion, mais il existe des limitations et des mises en garde. Par exemple, git-svn peut créer un dépôt qui reflète Subversion, et les modifications apportées à ce repo peuvent être renvoyées à Subversion via 'dcommit'. Mais la page de manuel git-svn met explicitement en garde contre la création de clones de ce dépôt, donc essentiellement, c'est une copie de travail de Subversion sur laquelle vous pouvez utiliser les commandes git. Bazaar possède également une fonctionnalité Subversion bidirectionnelle, mais sa documentation indique que les propriétés Subversion ne sont pas prises en charge du tout.

Voici la fin que je poursuis. Je veux un référentiel Subversion et un référentiel DVCS qui, à l'état stable, ont un contenu identique. Quand quelque chose est changé sur un, il est automatiquement reflété à l'autre. Les utilisateurs Subversion interagissent normalement avec le référentiel Subversion. Les utilisateurs DVCS clone le référentiel DVCS, en retire les modifications et y repousse les modifications. Plus important encore, ils n'ont pas besoin de savoir que ce référentiel DVCS spécial est associé à un référentiel Subversion.

Il serait probablement intéressant si n'importe quel clone du dépôt spécial est lui-même un dépôt spécial et pourrait commettre directement à Subversion, mais il pourrait être suffisant si seulement le référentiel spécial interagit directement avec Subversion.

Je pense que ce dont nous avons le plus besoin est d'améliorer la capacité bidirectionnelle afin que les modifications apportées aux propriétés de Subversion soient traduites en changements dans le référentiel DVCS. Certaines modifications dans le référentiel DVCS seraient traduites en modifications des propriétés Subversion.

Ou est la réponse pour créer une nouvelle fonctionnalité dans Subversion qui interagit avec un référentiel DVCS, en utilisant le référentiel DVCS comme une couche de stockage spéciale comme fsfs ou bdb?

S'il n'y a pas de correspondance directe entre ce que Subversion et un DVCS considèrent comme ayant des versions, cela implique-t-il qu'il y aura toujours une activité qui ne peut pas être enregistrée correctement sur l'un ou l'autre?

Answer 1

Ma conclusion après avoir réfléchi sur les réponses que j'ai eu plus quelques conversations avec d'autres est qu'il y aurait nécessairement besoin d'être un à un entre les choses que Subversion et les DVCS peuvent gérer. Si ce n'est pas le cas, la véritable interopérabilité ne peut pas exister.

Je ne pense pas qu'il existe des DVCS existants qui soient encore candidats pour cela. Comme le souligne Chris Kaminski, peut-être que Subversion s'attaquera au problème à l'avenir en incluant des capacités distribuées.

J'ai posé la question parce que je travaille dans une organisation où nous approchons de la fin d'une longue et pénible migration de CVS à Subversion. Subversion répond très bien aux besoins de l'organisation - à savoir, avoir une source de vérité centralisée. Il y a une vague mais croissante de sentiment parmi les programmeurs individuels qu'ils veulent utiliser git ou d'autres systèmes DVCS à la mode. Parce que git-svn est fondamentalement juste un client Subversion sophistiqué, il y a un moyen assez heureux. OTOH, avoir le référentiel centralisé peut causer des ennuis, par ex. quelqu'un qui travaille en Inde avec des centaines de millisecondes de latence au serveur. En outre, ce n'est qu'une question de temps avant que toutes nos nouvelles recrues apparaissent ne pas avoir utilisé autre chose que git/hg/bzr/quoi que ce soit. Je pense qu'ils vont avoir peur de vivre dans le monde du référentiel Subversion centralisé. Donc, je me demandais s'il y avait un moyen de l'avoir dans les deux sens: le référentiel Subversion que l'organisation veut et autour duquel de nombreux autres processus sont construits ET les nouveaux outils DVCS brillants que les programmeurs hipster exigent! Malheureusement, je pense que ce n'est tout simplement pas vraiment possible. Je pense que les concepts sous-jacents de Subversion sont obsolètes. Un jour, nous allons juste devoir prendre les choses à la légère et intégrer la technologie DVCS dans notre infrastructure, puis laisser les projets individuels décider s'ils veulent vivre dans un monde Subversion ou dans un monde DVCS.

Answer 2

Cela s'appelle git, et en utilisant git-svn vous pouvez interopérer avec les clients Subversion. La mise en garde sur git-svn n'est pas git < -> svn, c'est (git < -> git) < -> svn. Fondamentalement, ils disent que si vous utilisez git pour accéder à un référentiel SVN, NE partagez PAS votre dépôt git avec quelqu'un d'autre via push/pull. Sinon, cela fonctionne très bien. Vous obtenez principalement le contrôle de code source déconnecté d'un référentiel Subversion en réseau. C'est tout. Si vous voulez quelque chose d'un peu plus "pur", SVK est un DVCS construit sur Subversion, mais il a été abandonné par les auteurs (bien qu'il soit open source - PERL). Les gens de subversion ont certaines capacités DVCS sur la feuille de route, probablement stimulée par le succès de SVK et la prévalence croissante de git/mercurial/bazaar.

Answer 3

Je ne pense pas qu'il y ait vraiment une façon native de faire les deux outils entièrement inter opérable, surtout quand on considère que:

• SVN est un contrôle de révision qui émule les balises et les branches avec les répertoires
• SVN n'enregistre pas d'informations fusionner la façon dont Git ne

(voir SVN vs. Git)

Alors voulant que « DVCS côté nous Les utilisateurs n'ont pas besoin de savoir qu'un référentiel Subversion existe. " est un peu tiré par les cheveux, au moins sans un git intermédiaire comme Chris suggests in his answer.

Je voudrais simplement ajouter à évaluer svn2git et git2svn afin d'avoir vos « utilisateurs côté DVCS » portant sur git ne reflète pas « répertoires » qui aurait en fait dû branches.
(voir « Cloning a Non-Standard Svn Repository with Git-Svn »)