2010-03-29 4 views
5

Mon équipe utilise SVN pour le contrôle de source. Récemment, j'ai travaillé sur une branche avec des fusions occasionnelles du tronc et cela a été une expérience plutôt ennuyeuse (voir le "Subversion Story #1" de Joel Spolsky), donc j'ai cherché d'autres manières de gérer les branches et de fusionner. Étant donné qu'un référentiel SVN centralisé n'est pas négociable, j'aimerais un ensemble d'outils répondant aux conditions suivantes.Outils pour maintenir des branches dans SVN

  1. L'historique complet des révisions doit être stocké dans SVN pour les lignes réseau et les branches.

  2. La fusion dans l'une ou l'autre direction (et la possibilité de s'entrecroiser) devrait être relativement indolore.

  3. L'historique de fusion doit être stocké dans SVN dans toute la mesure du possible.

Je l'ai regardé à la fois git-svn et bzr-svn et ne semble être à la hauteur — essentiellement, compte tenu de l'historique de révision, ils peuvent exporter à partir du dépôt SVN, ils ne semblent pas faire mieux une la gestion des tâches fusionne que SVN peut. Par exemple, après avoir cloné le référentiel avec git, l'historique des révisions de ma branche montre la branche d'origine du tronc, mais git ne "voit" aucune des fusions SVN intermédiaires car "natif" fusionne — l'historique des révisions est long ligne. Par conséquent, toute tentative de fusion à partir du tronc dans git génère autant de conflits qu'une fusion SVN. (D'ailleurs, le git-svn documentation met explicitement en garde contre l'utilisation git de fusion entre les branches.)

Y at-il un moyen d'ajuster mon flux de travail pour faire git satisfaire les exigences ci-dessus? Peut-être que j'ai juste besoin de trucs ou astuces (ou d'un outil de fusion séparé?) Pour aider SVN à fusionner en branches.

+0

On dirait que vous devez vraiment convaincre votre équipe d'utiliser git. : P – Amber

+2

Je pense, malheureusement, que vous vous heurtez au fait que SVN est simplement limité dans sa capacité à fusionner des branches - et tant que votre repo central est un repo SVN, il est difficile pour toute quantité de magie git vous sauve. Je suis certainement curieux de voir s'il y a de bons kludges de travail! – Cascabel

Répondre

2

Sans avoir une réponse pur SVN, je voudrais me référer à la question SO « How to fool git-svn to recognize merges made with svn? »

Je recommande de faire les git se fond dans une branche spéciale, mais une solution plus simple serait d'enregistrer (au moins le plus récent) SVN fusionne dans le git-svn repo avec git grafts file clone, afin de transformer:

o-...-A---o---D--- unstable 
/  
X-----B---M---o---o--- stable 

en:

o-...-A---o---D--- unstable 
/  \ 
X-----B---M---o---o--- stable 

, facilitant le processus de fusion git, avant dcommit et renvoyant cela à SVN.

+0

Le fichier de greffe semble aider beaucoup, merci! Il semble suffisant d'ajouter une greffe juste pour la dernière fusion du tronc. Est-ce correct? Recommandez-vous d'utiliser 'git merge --squash' pour cacher le vrai DAG de SVN? Aussi, je me demande comment cela satisfait # 3 (bien que honnêtement, je ne suis pas sûr de la valeur de l'information de fusion à SVN)? –

+0

@Chris: après avoir lu http://stackoverflow.com/questions/2427238/in-git-what-is-the-difference-between-merge-squash-and-rebase, je ne pense pas à une «fusion de squash» est nécessaire ici. SVN peut utiliser le DAG pour enregistrer des métadonnées 'mergeinfo' pendant' dcommit'. – VonC

Questions connexes