Déplacer un dépôt SVN de plusieurs Go vers Git

13

Actuellement, mon entreprise a une solution Visual Studio dans un référentiel SVN qui est organisé comme suit:

SolutionFolder (~3.5 GB)
|-> SolutionName.sln
|-> .. Some source code folders... (~250 MB)
|-> ThirdParty (~3 GB)
|-> Tools
    | -> Tool1
    | -> Tool2

Tool1 et Tool2 sont construits indépendamment (ont leurs propres solutions), mais produisent des exécutables qui sont utilisés dans la build principale. Le dossier ThirdParty contient toutes les dépendances du projet, y compris certains fichiers .lib de plus de 100 Mo précompilés et de grandes bibliothèques comme boost.

Il est pratique de tout avoir dans un seul référentiel SVN pour que (1) le développeur n'ait à effectuer qu'une seule extraction, et (2) nous n'avons pas besoin de garder une trace des versions des dépendances dont nous avons besoin pour chaque version de la build. D'un autre côté, il faut un certain temps pour vérifier ce dépôt.

Quelle serait la meilleure façon de déplacer cette structure de projet vers git? Vraisemblablement, il est préférable d'exclure ThirdParty et éventuellement les outils du référentiel principal, mais nous aimerions garder ThirdParty facilement téléchargeable en une seule étape, et nous l'aimons versionné (et les décalages de version entre le référentiel principal et ThirdParty / Tools seraient mauvais).

À ce stade, je ne suis pas intéressé à préserver l'histoire, juste à trouver comment organiser un tel projet.

version-control git ikh
la source
Ces tailles sont-elles supérieures aux tailles dans les dépôts, y compris l'historique, ou sont-elles les tailles de la copie de travail locale?
Doc Brown
1
@DocBrown uniquement la copie de travail locale, n'inclut pas l'historique.
ikh

Réponses:

10

Utilisez l'outil approprié pour le travail. Sous Windows, cela signifie

Utiliser NuGet pour les dépendances tierces

De cette façon, vous conservez les dépendances tierces de manière versionnée, mais vous ne surchargez pas votre référentiel avec des éléments inutiles. Les extractions sont beaucoup plus rapides et le projet est organisé comme il se doit. Vous pouvez activer une option dans Visual Studio afin qu'elle télécharge toujours toutes les dépendances automatiquement.

Bien sûr, vous pouvez utiliser une solution qui utilise uniquement git (un autre dépôt, des sous-modules, etc.), mais ce ne sont que des hacks. Le faire de la bonne façon portera ses fruits rapidement et vous laissera un système évolutif.

Modifier après les commentaires: la meilleure façon d'utiliser NuGet est de configurer une source NuGet locale, soit sur un lecteur partagé, soit sur un serveur nuget complet. L'installation ne devrait pas prendre plus de quelques minutes dans les deux cas. De cette façon, vous pouvez garantir que tous les packages dont vous avez besoin sont toujours disponibles, peu importe d'où ils proviennent.

Wilbert
la source
NuGet prend-il en charge les versions de ligne de commande? Je suis toujours à la recherche d'une version portable que je peux faire construire et tester par Jenkins pour moi. NuGet prend-il en charge les serveurs CI comme Jenkins?
uncletall
Une dernière réflexion, combien de temps avez-vous besoin pour prendre en charge votre produit? Si vous devez fournir une assistance pendant très longtemps, je ne compterais pas sur la bonne version de vos bibliothèques tierces pour être disponible dans NuGet. Vous pourriez rencontrer de très gros problèmes en vous appuyant sur des outils comme NuGet pour obtenir la bonne combinaison d'outils tiers, même dans 2 à 3 ans.
déclassement le
3
@uncletall: oui, NuGet a une interface de ligne de commande complète. Et l'idée est de configurer un référentiel NuGet local, qui peut être simplement un dossier sur un partage réseau (appelé "feed", docs.nuget.org/docs/creating-packages/… )
Doc Brown
Oui, j'ai supposé bien sûr que vous utilisez un miroir local. Je mettrai à jour la réponse.
Wilbert
2
@ikh c'est assez simple et direct de construire des paquets de nuget pour les dépendances externes. J'avais besoin d'environ une demi-journée pour empaqueter 9 dépendances avec 50 dlls, sans l'avoir fait auparavant.
Wilbert
5

Vous pouvez utiliser des sous-modules pour les outils. De cette façon, vous pouvez les conserver dans un sous-répertoire comme vous le faites maintenant, et utiliser un référentiel séparé pour les versionner. Cela signifie également que vous pouvez cloner (extraire) les outils et les développer séparément, et que d'autres projets pourraient s'appuyer sur ces référentiels - et sur des versions spécifiques et modifiables d'entre eux également.

Vous pouvez également utiliser des sous-modules pour les bibliothèques tierces, mais si possible, je recommanderais d'utiliser un gestionnaire de dépendances pour celles-ci.

Idan Arye
la source
4

Les entités que vous transformez en référentiels git sont nécessairement les entités que vous versionnez et branchez; si SolutionFolder/Tools/Tool1correspond à une telle chose, c'est le niveau d'entité. C'est parce que git considère que l'état entier de l'arborescence de répertoires est l'entité versionnable, alors qu'avec svn il est possible (même si ce n'est pas une bonne idée) d'en avoir un trunk, brancheset tagsn'importe où dans l'arborescence.

Les artefacts dérivés ne doivent pas être conservés dans le référentiel, pas plus que les bibliothèques externes. Il existe de meilleures façons de les gérer. (Si vous travaillez avec Java, envisagez d'utiliser un référentiel Maven privé; ils sont relativement faciles à utiliser et s'intègrent bien à beaucoup d'autres choses.)

Si vous êtes habitué à un flux de travail qui contient tout dans un seul référentiel pour faciliter le paiement, pensez à avoir un script qui configure les choses à la place.

Associés Donal
la source
Quelles sont les options de gestion des bibliothèques externes? Nous travaillons sur Visual Studio avec C ++ et C #, donc Maven ne ressemble pas à un bon ajustement. Le principal problème ici est qu'avoir le ThirdPartydossier dans le dépôt est tellement pratique, et il est difficile de trouver une bonne alternative.
ikh
2
@ikh: Dans un environnement Visual Studio, vous utiliserez généralement Nuget pour cela, docs.nuget.org , qui est déjà inclus dans VS 2012 et les versions plus récentes.
Doc Brown
2

Pour être honnête, je ne changerais rien dans votre configuration. C'est exactement ce que nous faisons maintenant. Je jouais avec la mise en place d'un référentiel git séparé pour gérer la bibliothèque tierce que nous utilisons, mais je ne pense pas que cela pèse sur le coût de la portabilité. Désormais, tout développeur peut simplement commander et commencer sans avoir à effectuer aucune étape de configuration manuelle. Et je n'importe quel serveur / esclave de construction peut construire le projet. À moins que vous n'ayez plusieurs référentiels partageant les outils de tierce partie, je m'en tiendrai à votre configuration actuelle.

J'ai joué avec la configuration des outils tiers dans un référentiel séparé. Ensuite, j'ai eu un simple script batch lu un fichier texte avec une référence sha1 et vérifier la bonne version. Cela me permettrait d'avoir différentes versions tierces pour différents projets. J'ai eu cette idée avec l'outil de construction Facebook Buck. Mais au final, de nombreux développeurs n'aiment pas utiliser les outils de ligne de commande (boutique MS VC ici), j'ai donc abandonné l'idée.

L'une des principales raisons pour lesquelles vous ne devez pas télécharger vos bibliothèques tierces lorsque vous en avez besoin (à l'aide de NuGet) est que si vous devez prendre en charge votre produit pendant une longue période. Dans mon secteur, nous devons parfois fournir des mises à jour pour les anciennes versions qui reposent sur d'anciennes bibliothèques tierces. Nous ne voulons pas passer beaucoup de temps à trier les bibliothèques que nous pouvons mettre à niveau ou non et simplement utiliser les bibliothèques utilisées dans cette version. Imaginez maintenant que vous utilisez NuGet, oups ... la dernière version de la bibliothèque dont vous avez besoin est 3.98 mais vous avez besoin de 2.04 ..... comment expliquer à votre patron que vous devez passer 2 mois pour mettre à niveau l'ancienne version pour pouvoir d'utiliser les dernières bibliothèques quand il s'attendait à un petit changement!

déballer
la source
3
Bien que je vous ai donné un +1, étant donné que "laisser tout tel quel" est une solution pragmatique, je pense que les "repos multiples" ne sont peut-être pas le seul problème. Les DVCS comme Git encouragent à avoir plusieurs succursales locales et dans chaque succursale une copie locale complète de tout. Cela peut donc conduire à avoir plusieurs fois la même grande bibliothèque tierce (généralement la même version!) En tant que copie locale. Cela peut être faisable dans certaines situations, dans d'autres, je peux imaginer que cela aura un impact négatif sur les performances de branchement et de fusion.
Doc Brown
Pour autant que je sache, une branche est une opération très bon marché dans Git qui ne fera que créer un pointeur et occuper un espace presque nul.
uncletall
1
Relatif à @DocBrown: Que signifie «branchement gratuit» dans Git?
Sauf si je manque quelque chose, les branches sont "libres" dans Git. Je viens de vérifier mon .git / refs / head et toutes les branches sont des fichiers texte de 1 Ko, le .git / logs / refs / head contient les journaux où le plus grand est de 11 Ko pour le maître. Ma structure de projet normale est d'environ 500 Mo en code, bibliothèques tierces et autres outils. Je suis très heureux de prendre le coup de 1
Ko
1
@MichaelT: la branche elle-même est gratuite, bien sûr, mais je parle de la situation où vous avez plusieurs copies de travail de différentes branches sur votre poste de travail local en parallèle. Et si vous vérifiez les commentaires sous la question d'origine, l'OP faisait référence à 3 Go d'outils tiers comme étant la taille de la copie de travail.
Doc Brown