mikrocontroller.net

Forum: PC-Programmierung Versionierung für Anfänger


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: A. Z. (donvido)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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 Moderator
Autor: Bernd K. (prof7bit)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
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.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Hi.Lo. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> git verwenden statt svn.

Du hast das Problem des Fragestellers nicht verstanden.
Einfach SVN durch GIT ersetzen bringt hier doch garnix.

Autor: Ray M. (ray_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. Z. (donvido)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Wechsel von SVN auf Git sollte erstmal nicht zur Debatte stehen. Da 
wird es mit Sicherheit genug Widerstand innerhalb der Abteilung geben.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> git verwenden statt svn

Wie blöd ist das denn...

Autor: Ray M. (ray_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: Volle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ein Release in SVN wird durch ein TAG  festgelegt.
dahin kann du deine Bugfixes einbauen und dann einen neuen TAG anlegen

Autor: Erfahrener Entwickler (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Marten Morten (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Tobi P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: Noch eine Meinung (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: vn nn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: vn nn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: vn nn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jemand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.