Holy Cow

[/mecki78]

Demnächst wechseln dann vielleicht auch noch von Lochkarten auf Magnetspeicher.

/Mecki

[TrollNo1]

Was wäre denn dann dein Vorschlag, was sie benutzen sollen?

Alle Firmen, in denen ich bisher gearbeitet habe, haben SVN verwendet. Aktuell bin ich mir unsicher, ob wir mit Git die Hälfte der Entwickler nicht überfordern würden :D

Menschen, die mich im Internet siezen, sind mir suspekt.

[TheUnichi]

Ganz klare Sache: Du hast in Scheiß-Firmen gearbeitet.

GIT ist seit vielen, vielen Jahren, mind. seit einem Jahrzehnt, der Standard für alle großen Open Source Projekte, die existieren.

Selbst MICROSOFT hat den TFS aufgegeben um Git zu nutzen.

Wer da noch an SVN festhält, ist im falschen Beruf. Ganz einfach.

SVN ist komplexer, umständlicher zu handhaben, müllt das Dateisystem stärker zu und bietet ansonsten keine Vorteile gegenüber GIT.

[TrollNo1]

TheUnichi schrieb:
--------------------------------------------------------------------------------
> Ganz klare Sache: Du hast in Scheiß-Firmen gearbeitet.

Das kannst du nur anhand dieser einen Tatsache nicht sagen.

> GIT ist seit vielen, vielen Jahren, mind. seit einem Jahrzehnt, der
> Standard für alle großen Open Source Projekte, die existieren.

> Selbst MICROSOFT hat den TFS aufgegeben um Git zu nutzen.
>
> Wer da noch an SVN festhält, ist im falschen Beruf. Ganz einfach.

Als ob wir das so einfach entscheiden könnten. Wir sind weder Open Source noch ne reine Software Klitsche. Wir sind Maschinenbauer, Software ist da nur Nebenprodukt. Und wir haben nicht die Ressourcen, das mal schnell umzuziehen.

> SVN ist komplexer, umständlicher zu handhaben, müllt das Dateisystem
> stärker zu und bietet ansonsten keine Vorteile gegenüber GIT.

Bei uns hat es Vorteile: Alle wissen, wie sie damit umgehen müssen und es ist da und einsatzbereit.

Außerdem steht der SVN Server im Mutterkonzern, da können wir nicht einfach was eigenes aufziehen. Ich bin ja quasi froh, dass wir überhaupt ne Quellcodeverwaltung haben.

Menschen, die mich im Internet siezen, sind mir suspekt.

[/mecki78]

TrollNo1 schrieb:
--------------------------------------------------------------------------------
> Was wäre denn dann dein Vorschlag, was sie benutzen sollen?

Es geht nicht darum, was sie benutzen, sondern darum, dass sie es erst jetzt benutzen.

> Aktuell bin ich mir unsicher, ob wir mit Git die Hälfte der Entwickler
> nicht überfordern würden :D

Wer mit Git überfordert ist, der sollte definitiv nicht als Entwickler arbeiten, denn selbst Schüler schaffen es heute schon ihre Programmierprojekte auf GitHub zu hosten.

/Mecki



1 mal bearbeitet, zuletzt am 02.09.19 15:06 durch /mecki78.

[TrollNo1]

Nochmal, der Fokus bei uns liegt auf den Maschinen, nicht auf hochtrabenden Software-Architekturen. Für sowas gibts dann externe bzw. das wird ausgeschrieben und von Profis entwickelt. Wir machen dann eher die Features rein und beheben Fehler etc. Die Maschine muss laufen, egal wo der Quellcode verwaltet wird.

Menschen, die mich im Internet siezen, sind mir suspekt.

[/mecki78]

TrollNo1 schrieb:
--------------------------------------------------------------------------------
> Alle wissen, wie sie damit umgehen müssen

Und warum sind sie dann angeblich mit Git überfodert? Mit Git kannst du ganz genauso umgehen wie mit SVN. Das werden die wenigstens zwar lange tun, wenn sie merken, dass man mit Git auch viel produktiver umgehen kann, aber dazu ist ja niemand gezwungen.

> Außerdem steht der SVN Server im Mutterkonzern,

Und wo denkst du haben Firmen ihren Git Server stehen? Auf dem Mond? Unter dem Meer? In China? Kann es sein, dass du Git nur vom Namen her kennst?

/Mecki

[/mecki78]

TrollNo1 schrieb:
--------------------------------------------------------------------------------
> Nochmal, der Fokus bei uns liegt auf den Maschinen,

Keine Ahnung was das hier für eine Rolle spielen soll.
Überall wo du SVN nutzen kannst, kannst du auch Git nutzen.

> Wir machen dann eher die Features
> rein und beheben Fehler etc.

Auch hier, wenn ihr das bisher mit SVN machen konnten, dann könntet ihr das mit Git genauso machen, richtig angewendet sogar noch einfacher und komfortabler.

> Die Maschine muss laufen, egal wo der
> Quellcode verwaltet wird.

Auch das ist kein Argument gegen eine Nutzung von Git.

/Mecki

[TrollNo1]

Mal zusammengefasst:

Ich habe, als ich hier angefangen habe, versucht Git ins Spiel zu bringen. Wurde dann abgetan, dass sich da dann alle wieder einlernen müssen und wir haben keine Zeit für sowas.

Ich muss denen ja schon die Basics in SVN beibringen. Revisionen vergleichen bekommen sie grade noch hin, aber zwei Stände mischen? Never ever...

Dass der Server im Mutterkonzern steht heißt, dass die auch entscheiden, was wir einsetzen. Und der ganze Konzern nutzt SVN, fertig aus. Das muss man dann in den Meetings einbringen, mit allen diskutieren und dann müssen alle umstellen. Und es bringt unterm Strich erstmal keinen Cent Einnahmen.

In meiner vorigen Firma wurde nach und nach auf Git umgestellt, aber da war ich dann schon fast weg. Das war aber auch eine IT Firma und von denen erwarte ich das.

Erklär doch mal nem KFZ Mechaniker die Vorzüge von Linux und dass er seine Buchhaltung mit Libre Office machen soll. Der ist froh, dass es läuft und lässt da die Finger von.

Menschen, die mich im Internet siezen, sind mir suspekt.

[taifun850]

Die Maschine läuft nicht mit dem Quellcode, sondern mit dem Binärartefakt, dass aus einer Build-Pipeline rausfällt.

Git mit z.B. Bitbucket gibt dem Team erheblich bessere und strengere Möglichkeiten für den Reviewprozeß. Aber ich wette, dass Reviews bei euch eher seltener gemacht werden.

[Proctrap]

es gibt sehr gute UIs für git, nutze bspw SmartGit, bisher nur gute Erfahrung gemacht. Nimmt dir den alltag ab & kann auch Dinge wie interaktiver rebase etc.
Das Konzept Git wirst du ihnen aber beibringen müssen. Und da wirds bei anderen, modernen Systemen auch nicht einen Weg vorbei geben (mercurial, fossil & pijul). Ja einige davon haben eine bessere CLI oder schützen dich besser vor Datenverlust (auch git bessert die cli nach) aber grundlegend sind die Anforderungen heute einfach andere & daher muss man sich etwas damit beschäftigen.
Da gibt es dann aber auch zig Blogs, Anleitungen, Video & co um git zu verstehen.

Edit: ja manche der Konkurrenz Produkte haben bessere Eingliederung von CI, Issues & co, da ist git einfach modular.

ausgeloggt kein JS für golem = keine Seitenhüpfer



2 mal bearbeitet, zuletzt am 02.09.19 15:40 durch Proctrap.

[yoyoyo]

TrollNo1 schrieb:
--------------------------------------------------------------------------------
> Was wäre denn dann dein Vorschlag, was sie benutzen sollen?
>
> Alle Firmen, in denen ich bisher gearbeitet habe, haben SVN verwendet.
> Aktuell bin ich mir unsicher, ob wir mit Git die Hälfte der Entwickler
> nicht überfordern würden :D

Da kannste drauf wetten. Und die Tatsache, dass ein verteiltes VCS nicht trivial ist (kann man sich drüber streiten ob git da hilft oder im Gegenteil noch Öl ins Feuer gießt) hilft auch nicht weiter.
Bei dem Thema ist büffeln Pflicht und die Kandidaten, die die meisten Probleme haben sind nat . die die glauben das geht schon so...

[ManfredU]

TheUnichi schrieb:
--------------------------------------------------------------------------------
>
> Wer da noch an SVN festhält, ist im falschen Beruf. Ganz einfach.
>
> SVN ist komplexer, umständlicher zu handhaben, müllt das Dateisystem
> stärker zu und bietet ansonsten keine Vorteile gegenüber GIT.

Ich behaupte mal das Gegenteil: git ist komplexer, bietet dafür den Vorteil von verteilten Repositories. Wenn man die Vorteile nicht benötigt, ist der Umgang mit einem zentralen Repository bei svn sicherlich einfacher und gradliniger und ein Wechsel auf git nur die Lösung eines nicht bestehenden Problems.

Es hat ja auch schon seine Gründe, warum FreeBSD noch nicht komplett umgestiegen ist. In dem verlinkten PDF sind einige weiterführende Links zu dem Thema enthalten.

[TrollNo1]

Richtig, denn die, die das könnten, ersaufen in Arbeit. Ich mache hin und wieder Reviews. Heute eben per Compare Revisions und Emails. In der alten Firma hatten wir Phabricator.

Menschen, die mich im Internet siezen, sind mir suspekt.

[demon driver]

TheUnichi schrieb:
--------------------------------------------------------------------------------

> Wer da noch an SVN festhält, ist im falschen Beruf. Ganz einfach

Nö, du hast nur ganz einfach keine Ahnung von der Praxis. Wenn SVN in der Praxis funktioniert und seinen Zweck erfüllt und das auch für die absehbare Zukunft tut, warum ohne Not teure Arbeitskraft in einen komplexen Umstieg investieren?

[Akaruso]

Danke, so ist es. Für uns tut SVN vollkommen seinen Zweck, es läuft problemlos und wir kennen uns damit aus. Es gibt (für uns!) kein größeres Manko an SVN, welches den Aufwand der Umstellung rechtfertigen würde.
Die Arbeitskraft setzten wir lieber andersweitig ein.

[demon driver]

/mecki78 schrieb:
--------------------------------------------------------------------------------
> TrollNo1 schrieb:
> ---------------------------------------------------------------------------
> > Nochmal, der Fokus bei uns liegt auf den Maschinen,
>
> Keine Ahnung was das hier für eine Rolle spielen soll.

Das hast du richtig erkannt. Die Rolle heißt "Aufwand".

> Überall wo du SVN nutzen kannst, kannst du auch Git nutzen.

Ja und? *Muss* man etwas, nur weil man es kann? In jedem Betrieb, in dem SVN ohne akute Probleme seinen Zweck tut, gibt es gerne mal tausend andere Dinge, die man eher anfassen sollte, als ohne Not alles von SVN auf Git zu migrieren.

[schubumkehr]

Wenn ich an diese lästigen Directory-Tree-Konflikte oder "Dein SVN client passt nicht zum Server" Fehler denke, rollen sich bei mir die Fußnägel hoch. Ich bin froh seit fast 5 Jahren damit nicht mehr Arbeiten zu müssen. Ich bin froh, auch ohne Internet-Verbindung meine Changesets in Commits bündeln zu können oder mal einen commit noch amend'en zu können. Git hat eine gewisse komplexität (submodules etc), im Standard-Workflow ist es *exakt* so einfach wie SVN.

[spagettimonster]

Das ist ein Absprache, Enrichtungs- und Einführungsproblem, selbst sehr sehr sehr komplexe Anwendungen wurden bis ca. 2010 (eine erste CVS-Vorabversion war erst Ende 2005 verfügbar) völlig ohne solche ausgefeilten Versionsverwaltungssysteme entwickelt. D.h. es geht also auch völlig ohne, wenn man es nur will, z.B. dass man seinen Arbeitstand an z.B. einem Modul einer Software nach Vorgabe selbst in einer hirachischen Struktur (z.B. Datei-Ordner/Pfad) parkt, auf den berechtigte darauf Zugriff erhalten, rein mit Boardmitteln oder beliebigen (S)FTP-Client, ohne extra Tools dafür zur Hand zu bekommen die einem das Ein- und Auschecken, anlegen von Branches etc. mehr oder weniger abnehmen.



3 mal bearbeitet, zuletzt am 02.09.19 19:12 durch spagettimonster.

[elgooG]

Genau wie bei Git gibt es bei SVN keine Probleme wenn man damit umzugehen weiß. SVN ist schon lange äußerst sicher und stabil. Auch das einfache Auschecken von Subtrees ist ein Killerfeature.

Ich weiß beides zu schätzen und verwende beides in der Praxis. Eine Umstellung alter Projekte lässt sich einfach nicht rechtfertigen und ich werde Technologie ganz sicher nicht aufgrund von Ideologien oder Gruppenzwang auswählen.

Kann Spuren von persönlichen Meinungen, Sarkasmus und Erdnüssen enthalten. Ausdrucke nicht für den Verzehr geeignet. Ungelesen mindestens haltbar bis: siehe Rückseite