Git Clients

[Lethalis]

Hydra schreef op dinsdag 14 februari 2017 @ 14:51:
[...]
Tja. Ik vind dat gewoon een slap excuus. Als je met de developers vindt dat je over moet, moet het gewoon gebeuren. Kun je het beter eerder dan later doen, dan heb je er sneller profijt van. Daarnaast kost het maken van een git-repo gewoon geen tijd. Het importeren van SS history is misschien lastiger maar dan kun je ook gewoon die SS repo laten bestaan in een read-only mode. Iets minder handig misschien, maar een git repo maken is een paar minuten werk,

Het aanmaken van een git repo is idd een paar minuten werk, ervoor zorgen dat onze projecten zo ingericht zijn dat we ook optimaal gebruik van git kunnen maken daarentegen is heel veel werk

We hebben zelfs hybride VB6 / .NET applicaties.

Maar het grootste probleem zijn dus die libraries die overal en nergens gebruikt worden. We hebben dus een dependency hell die we eerst moeten oplossen (vandaar dat ik intern NuGet wil gaan gebruiken). Daarnaast moeten de projecten netjes in boomstructuren worden ingericht, zodat we ze ook netjes in git kunnen onderbrengen. Zodat we daarna ook duidelijke commits voor project X hebben.

[Sardaukar]

Lethalis schreef op dinsdag 14 februari 2017 @ 14:58:
[...]
We hebben zelfs hybride VB6 / .NET applicaties.

Wat maken jullie dan voor software als ik vragen mag?

[Kwistnix]

Sardaukar schreef op dinsdag 14 februari 2017 @ 14:55:
[...]


Redelijk kort door de bocht. Een organisatie met een monolitische applicatie waarbij alles in 1 versiebeheer systeem zit is niet in een ochtend overgezet naar een git workflow waarbij netjes dat hele project is omgezet in losse dependencies.

Dat hoef ook niet in één keer.
Je kan die monoliet toch ook overpompen in Git, zodat je in ieder geval a) SourceSafe een nekschot kan geven en b) als developers alvast aan de Git basics kan wennen. Dat de workflow dan alsnog verre van optimaal is, dat is dan voorlopig nog maar even een feit. Je kan vanuit dat punt in ieder geval wel verder optimaliseren. Baby steps.

[Hydra]

Sardaukar schreef op dinsdag 14 februari 2017 @ 14:55:
Redelijk kort door de bocht. Een organisatie met een monolitische applicatie waarbij alles in 1 versiebeheer systeem zit is niet in een ochtend overgezet naar een git workflow waarbij netjes dat hele project is omgezet in losse dependencies.

Dan snap ik, maar het blijft gewoon zo dat je dit een keer moet gaan doen. Het blijven vooruitschuiven is gewoon meer technische schuld opbouwen. Vandaar vind ik het een slap excuus. Wees dan eerlijk en zeg gewoon dat het je als bedrijf niet boeit dat je aan 't prutsen bent

Lethalis schreef op dinsdag 14 februari 2017 @ 14:58:
Maar het grootste probleem zijn dus die libraries die overal en nergens gebruikt worden. We hebben dus een dependency hell die we eerst moeten oplossen (vandaar dat ik intern NuGet wil gaan gebruiken). Daarnaast moeten de projecten netjes in boomstructuren worden ingericht, zodat we ze ook netjes in git kunnen onderbrengen. Zodat we daarna ook duidelijke commits voor project X hebben.

Jullie gebruiken geen tool voor je dependencies? Holy crap. Dat je dat volhoudt!

Kwistnix schreef op dinsdag 14 februari 2017 @ 15:07:
Dat hoef ook niet in één keer.
Je kan die monoliet toch ook overpompen in Git, zodat je in ieder geval a) SourceSafe een nekschot kan geven en b) als developers alvast aan de Git basics kan wennen. Dat de workflow dan alsnog verre van optimaal is, dat is dan voorlopig nog maar even een feit. Je kan vanuit dat punt in ieder geval wel verder optimaliseren. Baby steps.

Exact!

[ Voor 47% gewijzigd door Hydra op 14-02-2017 15:10 ]

[Sardaukar]

Hydra schreef op dinsdag 14 februari 2017 @ 15:08:
[...]
Dan snap ik, maar het blijft gewoon zo dat je dit een keer moet gaan doen. Het blijven vooruitschuiven is gewoon meer technische schuld opbouwen. Vandaar vind ik het een slap excuus. Wees dan eerlijk en zeg gewoon dat het je als bedrijf niet boeit dat je aan 't prutsen bent

Er zijn bedrijven genoeg die een product in zo'n structuur hebben zitten en daar blijkbaar nog mee kunnen werken ook. Zelfs Windows zelf zit in één gigantische repository waarvan de dependencies blijkbaar (nog) niet duidelijk te scheiden zijn. Mooi artikel daarover hier.

Microsoft is dan blijkbaar ook maar aan het prutsen volgens jou?

Beslissingen, zeker die met bedrijfs-economische impact worden nu eenmaal niet altijd alleen maar op basis van techniek genomen.

Dat gezegd hebbende: ik zou ook een traject in gang zetten om eens te kijken hoe je hier nu verder mee wilt gaan.

[Lethalis]

Hydra schreef op dinsdag 14 februari 2017 @ 15:08:
[...]
Dan snap ik, maar het blijft gewoon zo dat je dit een keer moet gaan doen. Het blijven vooruitschuiven is gewoon meer technische schuld opbouwen. Vandaar vind ik het een slap excuus. Wees dan eerlijk en zeg gewoon dat het je als bedrijf niet boeit dat je aan 't prutsen bent

Hoewel ik het theoretisch gezien met je eens ben, is de praktijk helaas wat minder rooskleurig.

Alles overharken naar git in 1 keer is niet te doen. Dan gaat er zoveel kapot dat wil je niet weten.

Een jaartje of 8 geleden heb ik zoiets dergelijks geprobeerd met Team Foundation Server. Dit leidde toen tot zoveel ellende dat we noodgedwongen terug moesten migreren naar SourceSafe. En sindsdien is het een moeilijk onderwerp.

En eerlijk is eerlijk, veel collega's boeit het echt niet. Die willen er zelf dan ook weinig tijd aan kwijt zijn.

Jullie gebruiken geen tool voor je dependencies? Holy crap. Dat je dat volhoudt!

Visual Studio stelt je in staat om dit heel lang vol te houden met project references. Je voegt simpelweg een bestaand project toe aan je solution (ook al staat dit project helemaal ergens anders op jouw schijf) en voegt daarna een directe reference toe aan deze project node. Bij het builden wordt de boel dan automatisch gecompileerd en meegenomen.

Met andere woorden, Visual Studio maakt het je heel makkelijk om te prutsen

Anyways, omdat de vorige migratie naar TFS een enorme afgang was, lijkt het mij veel verstandiger om dit in kleine stappen aan te pakken.

Mijn insteek is dan ook om eerst te beginnen met het gebruiken van NuGet en daarna de projecten stapsgewijs te ordenen, zodat ze daarna wel stuk voor stuk naar git kunnen. Eerst afsplitsen en dan verhuizen dus.

[Hydra]

Sardaukar schreef op dinsdag 14 februari 2017 @ 15:20:
Microsoft is dan blijkbaar ook maar aan het prutsen volgens jou?

Absoluut.

[Sardaukar]

Hydra schreef op dinsdag 14 februari 2017 @ 15:36:
[...]
Absoluut.

Niet eens een smiley? Disappointed

[Lethalis]

Sardaukar schreef op dinsdag 14 februari 2017 @ 15:01:
[...]
Wat maken jullie dan voor software als ik vragen mag?

Branchespecifieke software die bij aardig wat klanten in Nederland draait waar ze hun volledige administratie en bedrijfsprocessen mee ondersteunen. In grote lijnen software waar je orders intikt, voorraden in bijhoudt, facturatie mee doet, volledige boekhouding inzit, koppelingen met een hele reeks externe leveranciers, rapportages enzovoorts.

De eerste versie van de software was ooit een DOS pakket Daarna kwam de eerste Windows versie in VB6. En ik werk vooral aan de derde generatie die volledig in .NET geschreven is.

Maar de vorige versie heeft dus ook al wat .NET modules die via interop forms worden getoond Alles om te voorkomen dat je nieuwe VB6 code moet schrijven

[ Voor 9% gewijzigd door Lethalis op 14-02-2017 16:23 ]

[incaz]

Hydra schreef op dinsdag 14 februari 2017 @ 13:29:
[...]
Ik licht dit er even uit omdat dit nu precies het punt is; het kost je ff een paar uur.

Alleen is dit dus niet zomaar waar. Het kostte jou een paar uur. Mooi voor jou. Het kost veel anderen een paar uur - mooi voor hen. Het betekent zeker niet dat het iedereen een paar uur kost en dat het dan lukt en werkt, vooral niet omdat het heel erg gericht is op een bepaalde groep gebruikers met een bepaalde denkcultuur. Er zijn ook genoeg voorbeelden te vinden van ervaren developers die wel degelijk veel tijd hebben geinvesteerd in git en nog steeds tot dezelfde conclusies komen.

En ik hoor blijkbaar tot de mensen die niet het niet zomaar volgt. Mijn talenten liggen ergens anders: ik vind het daarom makkelijk om aan te sluiten bij veel gebruikers en hun intuities, maar moeilijk om aan te sluiten bij de structuur van git.

Dan kun je wel heel trots zeggen: 'jij faalt en ik deug' maar... het is nogal onaardig, vind je niet? Volgens mij zijn er heel veel verschillende eigenschappen die nuttig kunnen zijn in software development. En daarnaast is een beetje medemenselijkheid en respect eigenlijk ook nooit verkeerd. Zelfs al doet Linus het anders voorkomen.

[gekkie]

incaz schreef op dinsdag 14 februari 2017 @ 16:53:
[...]


Alleen is dit dus niet zomaar waar. Het kostte jou een paar uur. Mooi voor jou. Het kost veel anderen een paar uur - mooi voor hen. Het betekent zeker niet dat het iedereen een paar uur kost en dat het dan lukt en werkt, vooral niet omdat het heel erg gericht is op een bepaalde groep gebruikers met een bepaalde denkcultuur. Er zijn ook genoeg voorbeelden te vinden van ervaren developers die wel degelijk veel tijd hebben geinvesteerd in git en nog steeds tot dezelfde conclusies komen.

En ik hoor blijkbaar tot de mensen die niet het niet zomaar volgt. Mijn talenten liggen ergens anders: ik vind het daarom makkelijk om aan te sluiten bij veel gebruikers en hun intuities, maar moeilijk om aan te sluiten bij de structuur van git.

En wat bedoel je dan met "structuur", het zal waarschijnlijk niet over de innerworkings gaan, maar over de commando structuur ? best werkbare workflow ?

Mjah niet alles is even consequent, maar goed dat komt wel vaker voor, kennelijk bezit je soms toch de gave om je er te erg over opwinden dat je vindt dat het anders had gemoeten, maar niet bij machten bent om het zelf anders te maken, maar vervolgens je er wel tegen blijft verzetten.

Tevens ben ik nog steeds benieuwd hoe je git dan voornamelijk gebruikt.
Enerzijds meen ik dat je had aangegeven dat je het incidenteel gebruikt en daardoor niet echt routine krijgt en de ingewikkelde dingen onthoudt.
Maar anderzijds raak je ogenschijnlijk allerlei dingen kwijt, wat met de basis commando's en een vrij basic flow toch ook een bepaalde gave moet zijn. Kortom spaar je dan enorm veel uncommited werk op waar je dan in een brei verzuipt en tijdens committen gekke dingen mee doet, of wat doe je dan die keren dat je het wel gebruikt na zo'n grote tijdsspanne ?

Misschien werkt soms "go with the flow" toch wel beter in sommige gevallen, of uitkijken naar een alternatieve tool (mercurial, svn, cvs) of naar een alternatieve werkwijze.

offtopic:
PS. Overigens werkt "opensource" over het algemeen volgens het principe van "scratch your own itch". Als je mazzel hebt is er iemand met een zelfde itch (of er brood in ziet voor een semi commercieel product) en krijg je die feature, of heb je een zak geld en huur je een ontwikkelaar die het voor je maakt als je het zelf niet kunt, maar kennelijk zijn er in dit geval:

Of niet zoveel mensen met deze itch.
Of is het (op sommige vlakken) technisch niet mogelijk het te vereenvoudigen
Of hebben de mensen die deze itch voelen de combinatie van zelf niet de mogelijkheden om het te verbeteren en er ook geen geld voor over.

[ Voor 13% gewijzigd door gekkie op 14-02-2017 17:17 ]

[Hydra]

incaz schreef op dinsdag 14 februari 2017 @ 16:53:
Alleen is dit dus niet zomaar waar. Het kostte jou een paar uur. Mooi voor jou. Het kost veel anderen een paar uur - mooi voor hen. Het betekent zeker niet dat het iedereen een paar uur kost en dat het dan lukt en werkt, vooral niet omdat het heel erg gericht is op een bepaalde groep gebruikers met een bepaalde denkcultuur. Er zijn ook genoeg voorbeelden te vinden van ervaren developers die wel degelijk veel tijd hebben geinvesteerd in git en nog steeds tot dezelfde conclusies komen.

Onzin. Het is gewoon een kwestie van niet doorzetten. Je bent jezelf continue aan het wijsmaken dat je talenten "ergens anders liggen". Zoals iemand anders al zei; als je de tijd die je in dit topic had gestoken nou in het leren van Git had gestoken kun je prima een basis feature branch workflow gebruiken die ook in teams werkt.

Het is onmogelijk om niet in een paar uur de basis van git te snappen en ondertussen wel snugger genoeg zijn om aan complexe software te werken.

En ik hoor blijkbaar tot de mensen die niet het niet zomaar volgt. Mijn talenten liggen ergens anders: ik vind het daarom makkelijk om aan te sluiten bij veel gebruikers en hun intuities, maar moeilijk om aan te sluiten bij de structuur van git.

Ik heb geen enkel probleem om me te verplaatsen in gebruikers en hun intuities. De meeste goeie developers niet; je wordt namelijk betaald problemen op te lossen. Als je niet naar een gebruiker kunt luisteren ben je gewoon een slechte dev. Niks "anders denken". Het is niet het een of het ander. Kennelijk heb jij niet de basale technische skills en/of drive een tool te leren die de de facto standaard tegenwoordig is voor source control. Prima. Maar ga niet doen alsof je beter bent ofzo; het is gewoon een groot gebrek.

Ik stelde eerder de vraag hoe jullie peer review flow eruit ziet. Ik ben nog steeds erg benieuwd hoe jullie dat ingericht hebben zonder een goed version control systeem.

Dan kun je wel heel trots zeggen: 'jij faalt en ik deug' maar... het is nogal onaardig, vind je niet?

Nou en? Ik heb het je meerdere malen aardig gezegd. Dan vind je me maar onaardig. Ik heb echt nul komma nul met ontwikkelaars die hun vak niet serieus nemen. Ik mag namelijk veelal de rotzooi die ze veroorzaakt hebben komen opruimen. Je claims over Git (waarvan de claim dat Git meer een tool is voor product managers en systeembeheerders wel het toppunt is) zijn klinkklare onzin. Je blijft maar rare redenaties maken over waarom Git niet goed is. Source control is een core developer skill. Punt. Git is de de facto standaard. Punt. Hierover is gewoon geen discussie mogelijk. Als je dit vertikt te erkennen ben je wat mij betreft gewoon geen developer maar een amateur.

[gekkie]

Als is de vraag waarom git uiteindelijk meer tractie heeft gekregen van mecurial, heb zelf eigenlijk geen idee.

Het zou wellicht non-technisch van aard kunnen zijn, zoals github wat de doorslag heeft gegeven qua "marketing" tov bitbucket wat in die tijd dan weer mecurial hosting only was ?

[Brainstorm]

GitHub is zeker wel een grote factor geweest ja, hoewel in dit artikel uit 2014 gesteld wordt dat de funding en groei van GitHub pas op gang kwamen toen Git al populair aan het worden was. De primaire reden is juist de efficientere workflow voor developers. Een recenter artikel laat zo'n beetje hetzelfde zien. Je ziet in de grafiek ook dat Mercurial nog best wel aardig mee ging qua groei, tot 2012.

[gekkie]

Brainstorm schreef op dinsdag 14 februari 2017 @ 21:40:
GitHub is zeker wel een grote factor geweest ja, hoewel in dit artikel uit 2014 gesteld wordt dat de funding en groei van GitHub pas op gang kwamen toen Git al populair aan het worden was. De primaire reden is juist de efficientere workflow voor developers. Een recenter artikel laat zo'n beetje hetzelfde zien. Je ziet in de grafiek ook dat Mercurial nog best wel aardig mee ging qua groei, tot 2012.

Hmm als ik dat grafiekje moet interpreteren dan beginnen git en mercurial langzaam maar zeker uit elkaar te lopen na de intro van github. Volgende markante punt is bitbucket wat ook aan git gaat doen, vanaf dan lijkt eigenlijk de handdoek min of meer in de ring geworpen.
Al zijn er met mozilla, openjdk en python nog wel een aantal projecten die van mecurial gebruik maken.

[Hydra]

Brainstorm schreef op dinsdag 14 februari 2017 @ 21:40:
GitHub is zeker wel een grote factor geweest ja, hoewel in dit artikel uit 2014 gesteld wordt dat de funding en groei van GitHub pas op gang kwamen toen Git al populair aan het worden was.

Mooi: "It’s clear that now would be a good time to master Git.".

gekkie schreef op dinsdag 14 februari 2017 @ 18:44:
Als is de vraag waarom git uiteindelijk meer tractie heeft gekregen van mecurial, heb zelf eigenlijk geen idee.

Mercurial en Git zijn eigenlijk op hetzelde moment gestart en ik vermoed dat de keuze van het Linux kernel project samen met de naam van Torvalds ook erg geholpen heeft. Verder vond ik dit artikel wel een interessante verzameling argumenten.

[ Voor 29% gewijzigd door Hydra op 15-02-2017 08:23 ]

[Lethalis]

Ik denk ook dat het gebruiken van git voor het Linux kernel project mensen vertrouwen gaf. Zelf zie ik dat immers ook zo.

"Als een gigantisch project als de Linux kernel met git beheerd kan worden, dan moet het ook lukken voor onze eigen code"

Natuurlijk loop je dan tegen allerlei beperkingen van de Microsoft tools aan, zoals de manier waarop csproj en vbproj bestanden werken, waardoor je bij een merge pattern de hele dag niks anders aan het doen bent dan projectbestanden mergen Maar ja, daar kan git niks aan doen.

Ik heb samen - met veel andere developers - online veel gezeurd hierover bij Microsoft en ze bouwen gelukkig wildcard support in. MSBuild ondersteunde dit al langer, maar Visual Studio helaas niet. Dat .NET Core weer msbuild gaat gebruiken is voor ons indirect een zegen, omdat de tooling eindelijk een beetje aandacht krijgt.

Het liefste had ik gezien dat ze zoiets als Gradle zouden gaan gebruiken met een DSL, maar XML is altijd nog beter dan project.json voor het beschrijven van een project (kun je tenminste commentaar er in opnemen etc).

Ik bedoel, hoe moeilijk kan het zijn om gewoon met een build script te werken. Maar ja. Bij Java doen mensen niks liever dan XML laten verdwijnen en Microsoft brengt het terug. [/rant]

Wat dat betreft kan ik helaas ook niks anders concluderen dan dat Microsoft aan het prutsen is.

[Hydra]

Lethalis schreef op woensdag 15 februari 2017 @ 08:45:
Natuurlijk loop je dan tegen allerlei beperkingen van de Microsoft tools aan, zoals de manier waarop csproj en vbproj bestanden werken, waardoor je bij een merge pattern de hele dag niks anders aan het doen bent dan projectbestanden mergen Maar ja, daar kan git niks aan doen.

Gelukkig hebben we dat in Javaland al een jaar of 10 opgelost; niemand checkt IDE specieke meuk in

[Kwistnix]

En er is gelukkig ook zoiets als .gitignore of desnoods .git/info/excludes.

[gekkie]

Hydra schreef op woensdag 15 februari 2017 @ 08:23:
[...]
Verder vond ik dit artikel wel een interessante verzameling argumenten.

Thx, vanavond maar eens lezen

[Hydra]

Kwistnix schreef op woensdag 15 februari 2017 @ 11:26:
En er is gelukkig ook zoiets als .gitignore of desnoods .git/info/excludes.

Ja, dat is dus de manier waarop je standaard in Java projecten voorkomt dat Eclipse/IntelliJ/Netbeans project files ingecheckt worden. Zelfde geldt voor je build output.

[Kwistnix]

Hydra schreef op woensdag 15 februari 2017 @ 11:52:
[...]


Ja, dat is dus de manier waarop je standaard in Java projecten voorkomt dat Eclipse/IntelliJ/Netbeans project files ingecheckt worden. Zelfde geldt voor je build output.

Yep, maar ik neem aan dat dit geen mysterieuze Git feature is waarvan alleen Javanen het bestaan kennen.

[Brainstorm]

Nee, maar .csproj kun je simpelweg niet excluden omdat het geen tijdelijk of IDE-specifiek bestand is. Het bevat zeg maar de properties van een specifiek project, zoals references en andere instellingen. 1 van de nadelen is dat ze dus bijvoorbeeld bevatten "dit project is afhankelijk van library X versie Y". Op het moment dat je een nieuwe versie Z wilt gebruiken, verandert dus de inhoud van de csproj. En, om het leuk te maken, alle transitive dependencies worden ook expliciet opgenomen.

Dat, in combinatie met splitsen (Nuget packages, project references) maakt dat die files relatief vaak kunnen veranderen en dus gevoeliger zijn voor merge conflicten. MS heeft dat ook al lang geleden onderkent en probeert dat met .NET Core recht te trekken. Het is inderdaad erg tijdrovend namelijk

[Lethalis]

Kwistnix schreef op woensdag 15 februari 2017 @ 12:08:
[...]


Yep, maar ik neem aan dat dit geen mysterieuze Git feature is waarvan alleen Javanen het bestaan kennen.

Het grote verschil is dat je bij Java - zolang je een build tool gebruikt als Maven of Gradle - altijd de IDE specifieke bestanden kunt genereren.

Visual Studio en msbuild hebben echter al die project en solution files gewoon nodig om te werken. Als je die niet in source control opneemt, dan wens ik je veel succes bij het openen van een solution die tig dependencies heeft en uit meerdere projecten bestaat.

Of om het in C++ termen te zeggen: er is geen scheiding tussen de makefile en de IDE project files. Het is alles in 1.

Brainstorm schreef op woensdag 15 februari 2017 @ 12:55:
Dat, in combinatie met splitsen (Nuget packages, project references) maakt dat die files relatief vaak kunnen veranderen en dus gevoeliger zijn voor merge conflicten. MS heeft dat ook al lang geleden onderkent en probeert dat met .NET Core recht te trekken. Het is inderdaad erg tijdrovend namelijk

Het is alleen jammer dat ze dan eerst iets verzinnen dat nergens op slaat en door het bestandsformaat erg beperkt wordt (project.json), om vervolgens weer terug te gaan naar msbuild dat qua featureset het niet eens haalt bij wat in Java land Maven is.

Terwijl ze daar vaak al DSL's gebruiken, zoals bij Gradle, omdat XML omslachtig is en onhandig is om te mergen.

Zoals ik het zie, zou Microsoft met een nieuw formaat moeten komen waarin je een DSL kunt gebruiken.

Al is het friggin' VB for all I care:

code:

ProjectName = "Test"
AddReference("System.Drawing")
Target = "dll"

PublishTask {
  Target = "ftp://123.123.123.123/www/test"
}

Zoiets. Waarom kan de hele wereld dit wel, maar Microsoft niet? XML leest rot, merge't rot, is gewoon rot voor dit soort taken. En JSON is helemaal belachelijk. Je wil gewoon commentaar kunnen opnemen in de build files, andere build files kunnen includen, plugins kunnen gebruiken, enzovoorts.

[ Voor 56% gewijzigd door Lethalis op 15-02-2017 13:38 ]

[Kwistnix]

Lethalis schreef op woensdag 15 februari 2017 @ 13:10:
[...]

Het grote verschil is dat je bij Java - zolang je een build tool gebruikt als Maven of Gradle - altijd de IDE specifieke bestanden kunt genereren.

Visual Studio en msbuild hebben echter al die project en solution files gewoon nodig om te werken. Als je die niet in source control opneemt, dan wens ik je veel succes bij het openen van een solution die tig dependencies heeft en uit meerdere projecten bestaat.

Of om het in C++ termen te zeggen: er is geen scheiding tussen de makefile en de IDE project files. Het is alles in 1.

Ach so. Dat hebben die jongens van Microsoft dan goed voor elkaar anno 2017.

[Hydra]

Lethalis schreef op woensdag 15 februari 2017 @ 13:10:
Het is alleen jammer dat ze dan eerst iets verzinnen dat nergens op slaat en door het bestandsformaat erg beperkt wordt (project.json), om vervolgens weer terug te gaan naar msbuild dat qua featureset het niet eens haalt bij wat in Java land Maven is.

Terwijl ze daar vaak al DSL's gebruiken, zoals bij Gradle, omdat XML omslachtig is en onhandig is om te mergen.

Mwa. Het grote voordeel van Gradle is dat je complete build scripts in je build.gradle kan programmeren. Het grote nadeel van Gradle is dat mensen complete build scripts in hun build.gradle programmeren.

In teamverband heb ik dan ook liever Maven

[Lethalis]

Brainstorm schreef op woensdag 15 februari 2017 @ 12:55:
Nee, maar .csproj kun je simpelweg niet excluden omdat het geen tijdelijk of IDE-specifiek bestand is. Het bevat zeg maar de properties van een specifiek project, zoals references en andere instellingen. 1 van de nadelen is dat ze dus bijvoorbeeld bevatten "dit project is afhankelijk van library X versie Y". Op het moment dat je een nieuwe versie Z wilt gebruiken, verandert dus de inhoud van de csproj. En, om het leuk te maken, alle transitive dependencies worden ook expliciet opgenomen.

Dat, in combinatie met splitsen (Nuget packages, project references) maakt dat die files relatief vaak kunnen veranderen en dus gevoeliger zijn voor merge conflicten. MS heeft dat ook al lang geleden onderkent en probeert dat met .NET Core recht te trekken. Het is inderdaad erg tijdrovend namelijk

Maar je vergeet nog het leukste en dat is - zolang er geen wildcard support is - dat elk bestandje er in staat:

http://haacked.com/archiv...6/csproj-merge-conflicts/

Het formaat an sich zorgt ervoor dat je merge conflicts krijgt en het mergen ook nog eens mislukt.

Zodra jij alleen maar HelloWorld.cs toevoegt aan een project en een collega tegelijkertijd Test.cs, dan is het al klaar. Dat kan zich de gemiddelde Java dev niet eens voorstellen Die is gewend dat alles wat in zijn src map staat, simpelweg bij het project hoort. Dus wanneer meerdere mensen classes toevoegen, is er niks aan de hand.

Hydra schreef op woensdag 15 februari 2017 @ 13:40:
[...]
Mwa. Het grote voordeel van Gradle is dat je complete build scripts in je build.gradle kan programmeren. Het grote nadeel van Gradle is dat mensen complete build scripts in hun build.gradle programmeren.

In teamverband heb ik dan ook liever Maven

Daar is wel iets voor te zeggen.

Maar dan nog is een Maven bestand een stuk beter te behappen dan een csproj bestand. Je kan gewoon netjes alles zelf documenteren, parameters opnemen voor versies van libraries die bij elkaar horen (bijv. de versie van Spring), enzovoorts.

En omdat je niet elk class bestand apart hoeft te includen, kom je er ook veel minder vaak mee in aanraking.

Dit staat bijvoorbeeld in de csproj van een testproject van mij:

code:

<ItemGroup>
    <Compile Include="Models\AuthenticationLogon.cs" />
    <Compile Include="Models\AuthenticationRequest.cs" />
    <Compile Include="Core\WebTokenFunctions.cs" />
    <Compile Include="CustomBootstrapper.cs" />
    <Compile Include="Extensions\NancyModuleExtensions.cs" />
    <Compile Include="Modules\AuthModule.cs" />
    <Compile Include="Modules\HalloModule.cs" />
    <Compile Include="Modules\HalloSecureModule.cs" />
...

Elke class wordt vernoemd. Dat is echt killing voor het aantal merges.

MSBuild kan dit:

code:

<ItemGroup>
    <Compile Include="Models\*.cs" />
...

Maar als je dat dan met Visual Studio opent, dan maakt hij doodleuk al die entries weer automatisch aan

Gotta love it.

Visual Studio 2017 zou dit nu eindelijk niet meer doen. Ik ben benieuwd...

[ Voor 36% gewijzigd door Lethalis op 15-02-2017 14:01 ]

[Hydra]

Lethalis schreef op woensdag 15 februari 2017 @ 13:50:
Maar dan nog is een Maven bestand een stuk beter te behappen dan een csproj bestand. Je kan gewoon netjes alles zelf documenteren, parameters opnemen voor versies van libraries die bij elkaar horen (bijv. de versie van Spring), enzovoorts.

Precies. Dit is een willekeurig voorbeeld van een recente pom.xml, een build.gradle zou ongeveer dezelfde structuur hebben maar dan in Groovy.

Ik vind het ook altijd erg komisch als er weer op Reddit posts staan over nieuwe .Net Core releases met comments van mensen die menen dat Javanen nu en-masse overstappen op C#. De kracht van Java is niet Java zelf (C# is IMHO een betere taal), maar het ecosysteem.

[gekkie]

Wel mooi dat een git build gelijk een berg unittests draait, duurt alleen wel een tijdje voordat je pakketje eindelijk is compleet is

[Hydra]

gekkie schreef op donderdag 16 februari 2017 @ 10:49:
Wel mooi dat een git build gelijk een berg unittests draait, duurt alleen wel een tijdje voordat je pakketje eindelijk is compleet is

Hoe bedoel je? Falende tests breken bij ons altijd de build. Dan is de software stuk nl.

[gekkie]

Hydra schreef op donderdag 16 februari 2017 @ 13:02:
[...]


Hoe bedoel je? Falende tests breken bij ons altijd de build. Dan is de software stuk nl.

een dpkg-buildpackage van git duurt een aardige tijd, compileren valt wel mee, runnen van alle tig tests een behoorlijke tijd, maar goed allemaal voor het goede doel

[FRidh]

gekkie schreef op dinsdag 14 februari 2017 @ 22:10:
[...]
Al zijn er met mozilla, openjdk en python nog wel een aantal projecten die van mecurial gebruik maken.

Python zit sinds afgelopen vrijdag ook op GitHub

[Lethalis]

Hydra schreef op woensdag 15 februari 2017 @ 14:03:
[...]


Precies. Dit is een willekeurig voorbeeld van een recente pom.xml, een build.gradle zou ongeveer dezelfde structuur hebben maar dan in Groovy.

Ik vind het ook altijd erg komisch als er weer op Reddit posts staan over nieuwe .Net Core releases met comments van mensen die menen dat Javanen nu en-masse overstappen op C#. De kracht van Java is niet Java zelf (C# is IMHO een betere taal), maar het ecosysteem.

Ja ik geloof er ook niet in dat mensen gaan overstappen. Sowieso is dat niet te doen wanneer je met grote projecten werkt en een grote eigen verzameling van libraries hebt gemaakt.

Ik zit net zo vast aan .NET als jij aan Java waarschijnlijk. En zolang de .Net standard niet volwassen is, kan ik niet eens .NET Core gebruiken.

C# an sich is wel goed, maar begint ook gedateerd te worden wanneer je de taal met nieuwere talen als Kotlin, Scala of Swift gaat vergelijken.

Hoe hosten jullie eigenlijk de bare git repositories? Bij ons moet de code sowieso on premises blijven, dus online diensten vallen af.

Tot nu toe is gogs.io het leukste dat ik getest heb, maar misschien is er wel iets beters

[ Voor 3% gewijzigd door Lethalis op 16-02-2017 18:41 ]

[Bigs]

Zelf Gitlab hosten. Krijg je er meteen een issue tracker, CI etc bij.

[Lethalis]

Bigs schreef op donderdag 16 februari 2017 @ 18:44:
Zelf Gitlab hosten. Krijg je er meteen een issue tracker, CI etc bij.

De laatste keer dat ik gitlab heb getest, vond ik het een heel zwaar en traag pakket (qua memory usage etc).

Ook vond ik de backup en restore procedures ingewikkeld.

Ik zou bijna gewoon een Linux VM met alleen SSH gebruiken, maar iets zegt me dat mijn collega's dan gaan piepen dat het te ingewikkeld is

[Bigs]

Lethalis schreef op donderdag 16 februari 2017 @ 21:49:
[...]

De laatste keer dat ik gitlab heb getest, vond ik het een heel zwaar en traag pakket (qua memory usage etc).

Ook vond ik de backup en restore procedures ingewikkeld.

Ik zou bijna gewoon een Linux VM met alleen SSH gebruiken, maar iets zegt me dat mijn collega's dan gaan piepen dat het te ingewikkeld is

Tegenwoordig met Gitlab Omnibus is het uitrollen op een kale Linux VM wel heel eenvoudig en betrouwbaar. Maar als je alleen een git repo zoekt is iets als gitolite ook al voldoende natuurlijk. Gitlab draait bij ons (10 users) in een VM met 6GB RAM dus ja echt licht is het niet.

[Hydra]

Bigs schreef op donderdag 16 februari 2017 @ 18:44:
Zelf Gitlab hosten. Krijg je er meteen een issue tracker, CI etc bij.

Gitlab idd. Maar Jira voor issue tracking en Jenkins voor CI.

[Matis]

GitLab CI

[gekkie]

Bweg hebben die gitlab ruby jongens iets met go in elkaar proberen te klussen (gitlab-workhorse) maar die meuk compileert dus niet *zucht* geen zin om me te gaan verdiepen in go z'n package dependency management toolie. Dan maar de backup restoren en be done with it.

[Brent]

Lethalis schreef op donderdag 16 februari 2017 @ 21:49:
[...]

De laatste keer dat ik gitlab heb getest, vond ik het een heel zwaar en traag pakket (qua memory usage etc).

Je kunt dan Gogs/gitea.io eens proberen. Heeft inmiddels ook features als PR, issues.

[Lethalis]

Brent schreef op vrijdag 17 februari 2017 @ 12:52:
[...]

Je kunt dan Gogs/gitea.io eens proberen. Heeft inmiddels ook features als PR, issues.

Gogs.io heb ik thuis draaien. Enige wat ik eng vind, is dat het nog niet 1.0 is, dus ik vraag me af hoe de betrouwbaarheid van het geheel is. Voor thuis boeit dat niet zo, maar op mijn werk kan dat spannend zijn.

Kiezen tussen Gogs en Gitea vind ik ook moeilijk. Gitea is dan een fork van Gogs en noemt zich 1.0.1.

[update]
Ik heb Visual Studio 2017 RC geïnstalleerd en wat schetst mijn verbazing: ze hebben het csproj formaat alleen verbeterd voor .NET Core projecten. WTF Microsoft. Blijkbaar zitten we voor altijd vast in de project file merge hell.

Ze luisteren echt totaal niet daar, willen alleen maar hun .NET Core zooi doordrukken.

[ Voor 24% gewijzigd door Lethalis op 18-02-2017 08:04 ]

[GrooV]

Lethalis schreef op vrijdag 17 februari 2017 @ 14:34:
[...]

Gogs.io heb ik thuis draaien. Enige wat ik eng vind, is dat het nog niet 1.0 is, dus ik vraag me af hoe de betrouwbaarheid van het geheel is. Voor thuis boeit dat niet zo, maar op mijn werk kan dat spannend zijn.

Kiezen tussen Gogs en Gitea vind ik ook moeilijk. Gitea is dan een fork van Gogs en noemt zich 1.0.1.

[update]
Ik heb Visual Studio 2017 RC geïnstalleerd en wat schetst mijn verbazing: ze hebben het csproj formaat alleen verbeterd voor .NET Core projecten. WTF Microsoft. Blijkbaar zitten we voor altijd vast in de project file merge hell.

Ze luisteren echt totaal niet daar, willen alleen maar hun .NET Core zooi doordrukken.

Erg kortzichtig om .NET Core "zooi" te noemen, het klopt dat ze in het begin iets te enthousiast waren maar het is gewoon een goed product.

Het hele probleem is de backwards compatibiliteit. Ze willen niet de nieuwe .net core "zooi" doordrukken maar ze hebben juist .net core weer terug van project.json naar csproj's gebracht voor msbuild compatibiliteit.

.NET core is juist bedacht om een nieuw framework te maken wat niet alle legacy heeft. Anders was cross platform nooit mogelijk geweest.

[Lethalis]

GrooV schreef op dinsdag 21 februari 2017 @ 08:02:
[...]
Erg kortzichtig om .NET Core "zooi" te noemen, het klopt dat ze in het begin iets te enthousiast waren maar het is gewoon een goed product.

Het is vooral een onvolledig product dat naar mijn mening pas vanaf versie 2.0 enigszins bruikbaar wordt:

https://github.com/dotnet/core/blob/master/roadmap.md

.NET Standard 2.0 brengt eindelijk wat meer API's naar het platform.

Maar afgezien daarvan is het jammer dat alle aandacht daar naartoe gaat. Mijn grootste probleem is eigenlijk niet eens .NET an sich, maar Visual Studio. De Visual Studio tooling zou naar mijn mening uitgebreid moeten worden, zodat ik ook met "oudere projecten" gebruik kan maken van modernere csproj files bijvoorbeeld.

Het is absurd dat project files voor Windows Forms, WPF, ASP.NET full anno nu nog steeds elk bestand noemen. Wildcards zijn leuk, maar eigenlijk wil je simpelweg gewoon alle bestanden in de project tree by default includen. Maak het desnoods optout, maar niet meer optin.

We leven niet meer in 1990 verdorie.

Eigenlijk wil ik gewoon hetzelfde als bij Java, namelijk een eigen build systeem kunnen gebruiken dat het project beschrijft en desnoods de csproj en sln bestanden gewoon genereert voor me. Ik heb al zitten kijken naar diverse build systemen voor .NET, maar die hergebruiken allemaal msbuild en genereren zelf geen Visual Studio bestanden voor zover ik kan zien.

[ Voor 14% gewijzigd door Lethalis op 21-02-2017 11:01 ]

[GrooV]

Lethalis schreef op dinsdag 21 februari 2017 @ 10:58:
[...]

Het is vooral een onvolledig product dat naar mijn mening pas vanaf versie 2.0 enigszins bruikbaar wordt:

https://github.com/dotnet/core/blob/master/roadmap.md

.NET Standard 2.0 brengt eindelijk wat meer API's naar het platform.

Maar afgezien daarvan is het jammer dat alle aandacht daar naartoe gaat. Mijn grootste probleem is eigenlijk niet eens .NET an sich, maar Visual Studio. De Visual Studio tooling zou naar mijn mening uitgebreid moeten worden, zodat ik ook met "oudere projecten" gebruik kan maken van modernere csproj files bijvoorbeeld.

Het is absurd dat project files voor Windows Forms, WPF, ASP.NET full anno nu nog steeds elk bestand noemen. Wildcards zijn leuk, maar eigenlijk wil je simpelweg gewoon alle bestanden in de project tree by default includen. Maak het desnoods optout, maar niet meer optin.

We leven niet meer in 1990 verdorie.

Eigenlijk wil ik gewoon hetzelfde als bij Java, namelijk een eigen build systeem kunnen gebruiken dat het project beschrijft en desnoods de csproj en sln bestanden gewoon genereert voor me. Ik heb al zitten kijken naar diverse build systemen voor .NET, maar die hergebruiken allemaal msbuild en genereren zelf geen Visual Studio bestanden voor zover ik kan zien.

We gaan off-topic maar die build tools zijn er gewoon, zoek eens op CAKE of FAKE

[Lethalis]

GrooV schreef op dinsdag 21 februari 2017 @ 12:01:
[...]

We gaan off-topic maar die build tools zijn er gewoon, zoek eens op CAKE of FAKE

Ik heb naar Cake gekeken, maar kon daar niets vinden dat project files genereert?

Mijn idee is dan natuurlijk dat je alleen het cake buildscript naar git commit, en dat je lokaal de csproj genereert met Cake (of wat dan ook).

[ Voor 20% gewijzigd door Lethalis op 21-02-2017 12:19 ]

[GrooV]

Lethalis schreef op dinsdag 21 februari 2017 @ 12:16:
[...]

Ik heb naar Cake gekeken, maar kon daar niets vinden dat project files genereert?

Mijn idee is dan natuurlijk dat je alleen het cake buildscript naar git commit, en dat je lokaal de csproj genereert met Cake (of wat dan ook).

Vroegâh had je NMaven/NPanday

[Verwijderd]

Hi guys,

I'm developer of Fork.

I'm from Prague and I don't speak Dutch. So I used Google Translate and understood that you guys miss a possibility to see a diff between two commits .

Fork does have that feature already for about a month or so. To diff two revisions just hold the CMD key and select the commits you want to compare.

I'm open to requests, so if you miss any other feature in Fork feel free to contact me directly by email (or use the feedback button on the toolbar).

Regards,
Dan

P.S. BTW, it was really tricky to post that, because the whole Czech is banned on that website. I tried Tor, but it's blocked too. I sent an email to support, but they didn't answer.

[ Voor 14% gewijzigd door Verwijderd op 22-02-2017 18:56 ]

[Hydra]

Verwijderd schreef op woensdag 22 februari 2017 @ 18:52:
I'm developer of Fork.

Heh, cool Welcome! If you have any questions feel free to ask; we're happy to translate for you.

[Juup]

Verwijderd schreef op woensdag 22 februari 2017 @ 18:52:
... and understood that you guys miss a possibility to see a diff between two commits .

Fork does have that feature already for about a month or so. To diff two revisions just hold the CMD key and select the commits you want to compare.

Thanks Dan. I updated the topic startpost.