windows - Hvordan håndtere Git Submodules i Visual Studio løsninger med forskellige layout?

Indlæg af Hanne Mølgaard Plasc

Problem



Vi udvikler med Visual Studio 2010 (i C #) og flyttede for et stykke tid siden fra SVN til GIT. Nu forsøger vi at opdele vores lager (hvilket er ret stort - ~ 30.000 filer) til mange git repositories - en for hver løsning.
Løsningerne deler nogle projekter, for det meste biblioteker, vi udvikler internt og gerne vil føje til fra alle løsninger.


De nye repositorier har et fladt layout. Én underkatalog for hvert projekt (delte projekter er submoduler).
I den store gamle repo er projekterne i en træstruktur.


Problemet opstår med eksterne referencer i submodulerne. I den nye repos kan stien til et refereret projekt være '...... libs \ someproject', mens i det nye layout den korrekte sti ville være '.. \ someproject'.


Vi har allerede haft nogle redigeringskrige om dette og er ikke optaget af mere.


Halvbagt løsninger, jeg kunne tænke på:



  • brug 'Reference paths' i ... csproj.user og ekskluder denne fil fra versionskontrol (skal redone for hver udvikler og efter hver oprydning)

  • bruge grene til hver situation og forsøg at lære alle, hvor 'rigtige' forpligtelser skal gå, og hvor 'miljøskifte' begår, skal gå (submoduler er allerede ikke det enkleste begreb ...)

  • integrere binære filer i stedet for submodulerne (men hvad med at udvikle ændringer til submodulerne? Hvad med forskellige log4net-versioner?)



Er der nogen der kender til en sund løsning?

Bedste reference


Da du beder om en sund løsning, kan jeg kun rådgive dig til at se på at oprette din egen NuGet-tjeneste (se http://www.MyGet.org for inspiration) [1]


http://nuget.codeplex.com/[2]

Andre referencer 1


HVIS du går ned i pakken til rutevejledningen, overvejer OpenWrap. Imidlertid er indlejring af pakkehåndteringsgenstande i kildekode en dårlig idé. Du kan bruge sådanne værktøjer til at opdatere, hvad der faktisk gemmes i submoduler, men lad dem ikke være byggetid. Forvent binarierne at være der ud fra dine byggeskripts synspunkt.

Andre referencer 2


Så hvis jeg forstår dig korrekt, er problemet med Visual Studio og ikke med Git? Hvis det er tilfældet, skal du bruge den gamle træstruktur, der fungerede med Visual Studio. Gør dine submoduler også en træstruktur, så toppen af ​​træet ville være en super repo, hvis undermoduler (grene) ville have submoduler af deres Egen, indtil du kommer ned til træets blade. Det ville være en smerte at opsætte i starten, men det skal bare fungere.

Andre referencer 3


Brug en submodule til at huse alle 'fælles biblioteker'. Bare et niveau. Men du bør flytte de fælles biblioteker som tjenester med veldefinerede kontrakter. På denne måde kan du trinvis udbrede nye versioner uden nedetid. På denne måde har du kun en submodule i hver, der har kontrakterne. Disse kan være grænseflader eller meddelelser.

Andre referencer 4


Jeg har et lignende problem ved brug af VS 2013.


Jeg vil gerne bruge git-svn direkte i stedet for SVN. SVN har et gigantisk sæt af mapper. Jeg kunne ikke oprette et enkelt git-repository, der ville indeholde alle vores trunk mappe. Git - altid forsvundet med en fejl, og depotet var beskadiget. Jeg arbejdede rundt om problemet ved at gøre som følger:



  1. Brugte git-svn, jeg klonede delmængden af ​​mapper fra SVN/trunk, som jeg havde brug for ved at oprette et git-repository per mappe.

  2. Opret et lokalt git repository med alle mine git-svn-klonede mapper.

  3. Hver git-repository blev tilføjet som et undermodul til overordnet git-repository.



Problemet med Visual Studio er, at det ikke genkender de mange projekter uden for hovedprojektet, hvor jeg åbnede løsningen. Denne løsning findes i en mappe, der indeholder de eneste filer, der er anerkendt af Visual Studio, som værende under git-source-kontrol.


Jeg forsøgte at indstille git-præferencerne til at bruge overordnet overordnet mappe som placeringen af ​​git-repostitory uden at bemærke nogen forskel.