Ahoi miteinander, Ich wollte mir mal ein paar Tipps und Eindrücke in Sachen Versionierung holen und fragen, wie Ihr das machen würdet oder was ich besser machen könnte. Und zwar wird hier in meiner Abteilung ein Simulink Modell erstellt und gepflegt und mittels SVN versioniert. In einer anderen Abteilung wird, mit aus dem Modell erstellten Code, eine Lastenrechnung durchgeführt. Aktuell wird die Versionierung so gehandhabt, dass das Hauptmodell (für wichtige, offizielle Rechnungen) im trunk abgelegt ist und Änderungen, die bisherigen Code nicht ersetzten und Bugfixes auch dort eingepflegt werden. Wenn eine Änderung gefordert wird, die das Modellverhalten signifikant ändert, wird das in einen branch gelegt und gepflegt, bis die Bestätigung kommt, das auch ins Hauptmodell im trunk einzupflegen. Zur Unterscheidung der erzeugten Dateien wird eine Versionsnummer verwendet, die in jedem branch/trunk fortlaufend ist aber eindeutig jedem branch zuzuweisen ist. 2.1.x.y - trunk 2.2.x.y - branch1 2.3.x.y - branch2 ... Es gibt keine eindeutigen Releases, weil immer mal was geändert oder angepasst bzw. getestet wird. Dieses System stellt uns daher regelmäßig vor Probleme. So lassen Bugfixes sich später nichtmehr ohne separates Branchen erstellen, weil inzwischen weitere Änderungen eingeflossen sind. Manche Entwicklungen im trunk blockieren das Mergen oder Branchen weil zum Beispiel eine Schnittstelle grade geändert wird (ok hier könnte man auch die Änderung der Schnittstelle Branchen). Insgesamt wird aber der komplette Entwicklungsstamm immer unübersichtlicher und es fällt schwer den Überblick zu behalten. Wie lässt sich sowas also sinnvoller handhaben und warten? Vielen Dank schonmal für eure konstruktiven Antworten.
:
Verschoben durch User
A. Z. schrieb: > Insgesamt wird aber der komplette Entwicklungsstamm immer > unübersichtlicher und es fällt schwer den Überblick zu behalten. > > Wie lässt sich sowas also sinnvoller handhaben und warten? git verwenden statt svn.
Bernd K. schrieb: > git verwenden statt svn. Und dann einen definierten etablierten Workflow nutzen, z.B.: https://de.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow (geht auch nur mit git ohne Atlassian-Produkte)
Bernd K. schrieb: > git verwenden statt svn. Du hast das Problem des Fragestellers nicht verstanden. Einfach SVN durch GIT ersetzen bringt hier doch garnix.
A. Z. schrieb: > Ahoi miteinander, ... > Wie lässt sich sowas also sinnvoller handhaben und warten? https://www.veit-schiele.de/dienstleistungen/technische-dokumentation/git/git-flow
Der Wechsel von SVN auf Git sollte erstmal nicht zur Debatte stehen. Da wird es mit Sicherheit genug Widerstand innerhalb der Abteilung geben.
A. Z. schrieb: > Der Wechsel von SVN auf Git sollte erstmal nicht zur Debatte stehen. Da > wird es mit Sicherheit genug Widerstand innerhalb der Abteilung geben. Einen Tod musst du sterben ;) https://wissen.netzhaut.de/webentwicklung/subversion-in-grosprojekten-workflow/
ein Release in SVN wird durch ein TAG festgelegt. dahin kann du deine Bugfixes einbauen und dann einen neuen TAG anlegen
A. Z. schrieb: > Aktuell wird die Versionierung so gehandhabt, dass das Hauptmodell (für > wichtige, offizielle Rechnungen) im trunk abgelegt ist und Änderungen, > die bisherigen Code nicht ersetzten und Bugfixes auch dort eingepflegt > werden. [...] > Dieses System stellt uns daher regelmäßig vor Probleme. > So lassen Bugfixes sich später nichtmehr ohne separates Branchen > erstellen, weil inzwischen weitere Änderungen eingeflossen sind. > Manche Entwicklungen im trunk blockieren das Mergen oder Branchen weil > zum Beispiel eine Schnittstelle grade geändert wird Kommt mir alles bekannt vor. Das Hauptübel sind länger lebende Branches, gerade auch die Feature-Branches. Die funktionieren in den meisten Fällen überhaupt nicht gut. So ein Branch stirbt entweder ziemlich schnell ab mangels Wichtigkeit oder er entwickelt sich vom Stamm zu weit weg und lässt sich nicht mehr mergen. Die Lösung ist simpel: Genau andersherum vorgehen. Andere sind da auch schon auf die Idee gekommen: https://trunkbaseddevelopment.com/ Kurz zusammengefasst: Alle Entwicklungsarbeit findet im master (trunk) statt. Dort spielt das Leben. Ein Release ist ein Branch (und Tag). Denn genau das ist ein Release: Ein "Snapshot" einer kontinuierlichen Entwicklung. In den meisten Fällen muss auf so ein Release (Branch) eben später noch hier und da ein paar Bugfixes eingebaut werden. Aber je älter das Release, desto geringer die Wahrscheinlichkeit dafür. Die allgemeine Aufmerksamkeit widmet sich nämlich dem neuem Release. Das ältere Release "stirbt". Das passt zur natürlichen Entwicklung eines Branches. Und dann noch CI und CD, und der Laden flutscht! Änderungen die sich über einen längeren Zeitraum ziehen, kann man schön mit Feature-Flipper erschlagen. Dabei aber darauf achten, dass der Flipper zeitnah migriert wird. Was man nicht haben will, sind unzählige Feature-Flippers mit gegenseitigen Abhängigkeiten. Das wäre die Hölle.
Erfahrener Entwickler schrieb: > Die Lösung ist simpel: Genau andersherum vorgehen. Andere sind da auch > schon auf die Idee gekommen: > > https://trunkbaseddevelopment.com/ > > Kurz zusammengefasst: Ist ja lustig. Auf der Seite werden 30, 40 Jahre alte Grundregeln als neue Erkenntnisse verkauft. Ursprünglich hatte das SCCS Anfang der 70ern nicht mal nennenswerte Branches http://basepath.com/aup/talks/SCCS-Slideshow.pdf Die wurden erst gegen Mitte/Ende der 70er hoffähig. Seither stand in jedem SCCS-Handbuch wie http://www.bitsavers.org/pdf/sun/sunos/4.1/800-3847-10A_Programming_Utilities_and_Libraries_199003.pdf, Seite 108, zu Branches: ------------------------------------------------------------------------ -- However, situations can arise when it is convenient to create an alternate branch on the tree. For instance, consider a program that is in production use at version 1.3, and for which development work on release 2 is already in progress. Thus, release 2 might already have some deltas. Assume that a user reports a problem in version 1.3 which cannot wait until release 2 to be corrected. The changes necessary to correct the problem will have to be applied as a delta to version 1.3. This requires the creation of a new version, but one that is independent of the work being done for release 2. The new delta thus occupies a node on a new branch of the tree. The SID for a branch delta consists of four parts: the release and level numbers, and the branch and sequence numbers: release.level.branch.sequence The branch number is assigned to each branch that is a descendant of a particular trunk delta; the first such branch is 1, the next one 2, and so on. The sequence number is assigned, in order, to each delta on a particular branch. Thus, 1.3.1.1 identifies the first delta of the first branch derived from delta 1.3, as shown in the following figure. ------------------------------------------------------------------------ -- > Und dann noch CI und CD, und der Laden flutscht! Hach sind wir modern ... Ich verweise mal auf das oben bereits zitierte Paper von Rochkind von 1975, Seite 1 (364), vorletzter Absatz: >> Usually (but not necessarily), the first few deltas correspond to the >> initial changes that are made to new modules: correcting syntax errors >> and bugs found by "unit testing." Es ist nicht so, dass Unit Testing von den CI-Leuten in den 90ern erfunden wurde. Auch nicht die Automatisierung von Unit Tests als Basis von CI. Seite 6 (369): >> In fact, we went beyond the original, limited, goals of SCCS and >> set out to design a complete project design ... which we called the >> "Programmer's Workbench." ... other components include ... a load >> and regression testing facility for IBM IMS [8] and Univac BICS1100 [9] >> projects. Ach, würde man in der Informatik doch endlich aus der eigenen Geschichte lernen, statt alle Jahre wieder alles mit dem Arsch einreißen, was Vorgänger mühsam mit den Händen aufgebaut haben. Nur, um es ein paar Jahre später als neu Sau durchs Dorf zu treiben.
Marten Morten schrieb: > Ach, würde man in der Informatik doch endlich aus der eigenen Geschichte > lernen, statt alle Jahre wieder alles mit dem Arsch einreißen, was > Vorgänger mühsam mit den Händen aufgebaut haben. Alte Software geht ja nicht kaputt. Wenn es doch alles schon gibt, kann man das ja verwenden. Die Informatiker nehmen dir das nicht weg.
A. Z. schrieb: > Es gibt keine eindeutigen Releases, weil immer mal was geändert oder > angepasst bzw. getestet wird. Warum nicht? Dein System Trunk und Branch zu unterscheiden ist doch schon OK. Dann noch einfach die Buildnummer mit in die Version und alles ist eindeutig. Tags sind dabei überflüssig, es sei denn, Du arbeitest mit head-Externals, dann mag das sinnvoll sein (da Jedes Tag dann die Externals von head auf konkret setzen muss).
A. Z. schrieb: > Wie lässt sich sowas also sinnvoller handhaben und warten? Evtl. anders managen. Die Schnittstelle (die ja nichts mit der Programmfunktion zu tun hat) kann ein eigenes Modul werden (also auch eigenes Repo) mit entsprechender Historie. Der interne Kram lässt sich über Versionierung nicht lösen. Unabhängig davon ob git svn hg oder ... zum Einsatz kommt. Das muss man managen (hieß mal planen und kontrollieren) was ohne Aufwand nicht möglich ist. Dafür würde ich ein Ticketsystem verwenden. Nicht weil das jetzt so die Lösung aller Probleme bedeutet sondern weil es die Aufgaben besser trennt, zuteilt, den Status überwacht und eine Diskussion ohne Sourcecode ermöglicht. So nebenbei hat man über die Ticketnummer noch eine Versionsdoku.
Erfahrener Entwickler schrieb: > Änderungen die sich über einen längeren Zeitraum ziehen, kann man schön > mit Feature-Flipper erschlagen. Das ist jetzt nicht Dein Ernst? Schon erstaunlich was man sich alles schönreden kann wenn man auf Branches verzichten muss weil einem das Steinzeit-VCS von dem man sich aus Nostalgiegründen nicht trennen will das Arbeiten mit Branches zur Hölle macht. Dann schüttet man lieber seien Code mit ifdefs voll bis keiner mehr durchblickt anstatt einfach schnell und sauber nen separaten Branch dafür zu machen.
Hmm... hört sich eher so an, als läge das Problem woanders. Ihr müsst den ganzen historisch gewachsenen Wust in unabhängige Module aufteilen. Wenn eine Änderung an der Technik das Mergen von Anwendungsfeatures verhindert, hilft bessere Versionierung nicht mehr. Da musst ihr Technik und Anwendungslogik trennen.
Bernd K. schrieb: > Erfahrener Entwickler schrieb: >> Änderungen die sich über einen längeren Zeitraum ziehen, kann man schön >> mit Feature-Flipper erschlagen. > > Das ist jetzt nicht Dein Ernst? Schon erstaunlich was man sich alles > schönreden kann wenn man auf Branches verzichten muss weil einem das > Steinzeit-VCS von dem man sich aus Nostalgiegründen nicht trennen will > das Arbeiten mit Branches zur Hölle macht. Keine Frage, dass git doch um einiges komfortabler ist als SVN, aber wo genau verortest du das konkrete Problem, das einen dazu nötigt, in SVN auf Branches zu verzichten? Ein vernünftiger Workflow funktioniert auf git und auf SVN.
vn nn schrieb: > das einen dazu nötigt, in SVN > auf Branches zu verzichten? Es ist eine unglaublich schwergewichtige Operation die mit dem Kopieren des ganzen Verzeichnisses einhergeht und auch auf dem Server erfolgen muß. In git hast Du einen Branch erzeugt oder zerstört in wenigen Millisekunden denn da ist das nur ein Schildchen das an einen Commit angeheftet wird. SVN ist wie auf einem altersschwachen Elefanten herumzureiten während Git im selben Vergleich einer leichten Motocrossmaschine entspräche. Deshalb macht man in Git ohne mit der Wimper zu zucken mal schnell einen lokalen Branch wann immer man einen braucht, selbst für Kleinigkeiten die nur ne Stunde dauern um mal was auszuprobieren, weils halt so unbürokratisch und kostenlos ist wie ein masseloses post-it am Kühlschrank, in SVN denkt man nichtmal im Traum an sowas, womöglich müsste man einen neuen Branch erst beim Admin schriftlich beantragen und begründen. In der gleichen Zeit hast Du in git Deinen Branch gemacht, das getan was Du tun wolltest und bei Erfolg das Ergebnis wieder in Deinen Entwicklerzweig gemerged.
Bernd K. schrieb: > Es ist eine unglaublich schwergewichtige Operation die mit dem Kopieren > des ganzen Verzeichnisses einhergeht Sagt Dir "billige Kopie" etwas? Das ist das Gegenteil von schwergewichtig.
Bernd K. schrieb: > Es ist eine unglaublich schwergewichtige Operation die mit dem Kopieren > des ganzen Verzeichnisses einhergeht Ja, wirklich unglaublich schwergewichtig. Ach ne, doch nicht, macht ja eh der Server für mich. Ich klicke einfach auf "Branch". Und nein, ein SVN-Branch legt keine Kopie am Filesystem an, sondern lediglich einen Datenbankeintrag, genau wie in git. Aber das weißt du natürlich nicht, denn du trollst ja nur. Tatsächlich kann die Tatsache, dass SVN alles am Server macht, sogar hilfreich sein: wenn ich nach drei Wochen aus dem Urlaub zurückkomme und ein SVN Update mache, müssen nur die differenziellen Änderungen zwischen vor drei Wochen und jetzt übertragen werden, während ein git pull die ganze History runterlädt (die ich dann halt auch verfügbar habe, womit wir wieder bei den git-Vorteilen wären). Bernd K. schrieb: > selbst für Kleinigkeiten > die nur ne Stunde dauern um mal was auszuprobieren, weils halt so > unbürokratisch und kostenlos ist wie ein masseloses post-it am > Kühlschrank, in SVN denkt man nichtmal im Traum an sowas, womöglich > müsste man einen neuen Branch erst beim Admin schriftlich beantragen und > begründen. In der gleichen Zeit hast Du in git Deinen Branch gemacht, > das getan was Du tun wolltest und bei Erfolg das Ergebnis wieder in > Deinen Entwicklerzweig gemerged. Komische Firma wo du da arbeitest, wo man einen SVN-Branch beim Admin beantragen muss. Bei und hat man halt einfach gebrancht als wir noch SVN verwendeten, genau wie in git jetzt auch. Auch, wenn der Branch nach einer Stunde schon wieder gemerged wurde. Aber womöglich hast du ja auch selbst keinerlei Praktische Erfahrung mit den Tools, sondern beziehst dein Wissen nur aus irgendwelchen schlauen Foren oder Memes. Deswegen merkst du in deiner Abgehobenheit auch nicht, dass der TS erstmal einen neuen Workflow braucht, bevor er über neue Tools nachdenkt. Ja, git hat viele Vorteile, aber "langwieriges branchen, das erst beim Admin beantragt werden muss" ist schlichtweg lächerlich.
A.S. schrieb: > Bernd K. schrieb: >> Es ist eine unglaublich schwergewichtige Operation die mit dem Kopieren >> des ganzen Verzeichnisses einhergeht > > Sagt Dir "billige Kopie" etwas? Das ist das Gegenteil von > schwergewichtig. Nein, sagt ihm nichts. Er hat nämlich keine Ahnung, wie SVN funktioniert. Bei git wohl eben so wenig, aber das ist halt gerade hip. Welche Vor- und Nachteile beide Systeme tatsächlich haben, und wann und warum sich ein Wechsel lohnt, weiß er eigentlich nicht.
vn nn schrieb: > dem Urlaub zurückkomme und ein SVN Update mache, müssen nur die > differenziellen Änderungen zwischen vor drei Wochen und jetzt übertragen > werden, während ein git pull die ganze History runterlädt Stimmt, wenn man git nicht bedienen kann. Womit wir dann wieder bei > Aber das weißt du natürlich nicht, denn du trollst ja nur. sind. :^) SCNR
Volle schrieb: > ein Release in SVN wird durch ein TAG festgelegt. > dahin kann du deine Bugfixes einbauen und dann einen neuen TAG anlegen An Tags bastelt man nicht rum. Die erzeugt man einmal, und dann editiert man da tunlichst nichts mehr dran rum. Bernd K. schrieb: > in SVN denkt man nichtmal im Traum an sowas, womöglich > müsste man einen neuen Branch erst beim Admin schriftlich beantragen Es ist nicht die Schuld von SVN, wenn du bei deinem Admin jeden Firlefanz schriftlich beantragen musst. vn nn schrieb: > Tatsächlich kann die Tatsache, dass SVN alles am Server macht, sogar > hilfreich sein: Wer noch das davor gängige CVS kennt, weiß zu schätzen, wie viel SVN schon ohne Server macht. Damals sagte man noch, dass SVN ja für fast nichts mehr den Server braucht. ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.