Planification de la structure du référentiel pour la migration git

Question

J'ai actuellement un référentiel SVN important (30K validations) que je suis en train de convertir en git. Notre base de code a actuellement un ensemble commun (Core) de code, ainsi que deux bases distinctes (Java et .NET). Cela nous permet de partager du code commun ainsi que d'avoir des langages différents lorsque nous envoyons un build à un client qui ne supporte que l'une des deux langues.

Le référentiel SVN fait actuellement un usage intensif de svn: externals pour produire une mise en page spécifique à la caisse qui utilise le code commun, ainsi que le code spécifique au langage.

Une version allégée de la mise en page du référentiel est la suivante:

Core 
+ 
+-->classes 
+-->public_html 
    +>admin 
    +>web 
     +>images 
     +>javascript 
     +>styles 

Java 
+ 
+-->public_html 
    +>web 
     +>includes 
     +>code 


.NET 
+ 
+-->public_html 
    +>web 
     +>includes 
     +>code 

Actuellement quand j'extraction à partir tronc SVN, je vais obtenir la disposition ci-dessus sur le disque, si j'extrayez une sous-dossier (Java ou .NET), svn: externals me donnera la disposition suivante:

Java/.NET 
+>classes 
+>public_html 
    +>admin 
    +>web 
    +>code 
    +>javascript 
    +>images 
    +>includes 
    +>styles 

Cela aussi me permettre de modifier le code dans ce dossier, et faire un checkin s'engagera à la bonne place dans le référentiel. Ma question est de savoir si cela va être réalisable en git, en utilisant des sous-modules ou une autre méthode, ou si nous devons repenser toute notre mise en page et comment réaliser ce que nous voulons quand il s'agit de faire un checkout d'une branche pour créer une build. Si nous pouvons le faire avec des sous-modules, devrais-je suivre les didacticiels sur les sous-modules standard, ou y a-t-il quelque chose de plus en profondeur que je devrais regarder?

Merci!

Answer 1

Vous n'obtiendrez pas cette structure de répertoire exacte avec des sous-modules, car chacun sera dans son propre répertoire dans le référentiel parent.
Ie, vous obtiendrez

Java 
+ 
+-->public_html 
*-->Core 
     + 
     +-->public_html 

(au lieu d'un mélange « public_html »)

Je recommande toujours sous-modules (et vous pouvez faire modifier directement en eux, comme cela est expliqué dans le « True nature of submodules ») .
Cependant garder dans ce git submodules are quite different from svn:externals.

Une fois que vous avez récupéré le repo Java (avec une référence dans le repo Core), je recréerais la structure de répertoire correcte avec liens symboliques (disponible sous Unix ou Windows).