Bazaar-Notes
From Java4c
@ident=Bazaar_notes
This size is in german, because it is discussed in a german team. It will be presented in english in the future. TODO
Contents |
Kurzer Abriss, Arbeit mit MKSSI, git, mercurial, Bazaar
Hartmut: MKSSI ist seit über 10 Jahren bei mir in Gebrauch.
- Nur auf Arbeit, zentrale Administration,
- Die MKSSI-Software wird normalerweise nicht ständig updated. Das Arbeiten ist nicht sehr schnell, eher etwas für ordentliche Pflege.
- Wird gemacht, für die Versionen, die herausgegeben werden. Nicht für stündliche kleine Änderungen. Da wäre der Arbeitsaufwand zu hoch.
Hartmut: git war das erste der 'dritten Generation' für mich.
- Geht ganz gut, init commit, alles ganz einfach
- Nachschauen der Änderungen: Hier ist die GUI (gitk) nicht sehr bedienerfreundlich. Die schnelle Tastaturbedienung ist mangelhaft, der Tastaturfokus ist im falschen Teilfenster. Immer mit Maus schieben ...
- Linux-like cmdline-Bedienung auf Windows-PC ist für mich eher interessant.
Hartmut: mercurial - ähnlich wie git, nur eher für windows, eigentlich sehr ähnlich git.
Hartmut: Bazaar gefällt mir persönlich wegen der GUI besser.
Hartmut: Alle drei Systeme sind aber funktionell eher ähnlich. Ich pflege Quellen in Bazaar, um sie dann auch in hg zu committen, mit selbigem commit-Text wie in Bazaar zuvor zusammengestellt. Das ist nur ein Aufruf. Ein Hg-Archiv beispielsweise für CRuntimeJavalike liegt auf [bitbucket.org/jchartmut/cruntimejavalike]. Hg deshalb, weil die bitbucket-Seite nur hg unterstützt. Der Aufwand, in hg doppelt zu pflegen, ist kaum erhebenswert.
- Commit-Text zusammenstellen
- Vorderhand geht es beim Commit-text darum: Was leistet diese Version insgesamt, unterschied zur Vorversion. In der Zweiten Linie geht es aber um die Änderung in den einzelnen Files.
- Sind im Commit sehr viele Files enthalten, dann handelt es sich meist um das Ergebnis eines Refactoring wegen einer Änderung. Solche Änderungen brauchen in den Quellfiles nicht vermerkt werden, zuviel Aufwand, uninteressant.
- Sind dagegen wenige Files geändert, dann lag meist auch eine Änderung der Funktionalität vor. Diese sollte unabhängig vom Commit in den Quellfiles notiert werden. Hier hilft aber die Differenzanzeige, um während des Commit die Änderungen in den Files zu vermerken. Man kann einen passenden Commit-Text zusammenstellen, dabei die Änderung der Einzelfiles betrachten und dabei in den Einzelfiles Änderungen notieren (log des Files).
- Ein automatisches Eintragen der Änderung in den Files aus dem checkin-Textes aus der Arbeit mit dem Source-Integrity-System produziert meist Einträge in den Files, die die Änderungen schlecht abbilden. Das liegt daran, weil der Arbeitsaufwand für jeden Einzelfile zu hoch ist. Dieses automatische Eintragen ist aber eine häufig verwendete oder voreingestellte Methode bei MKSSI & co.
- Der Arbeitsaufwand bei manuellem Eintragen in den File ist deshalb bei Bazaar geringer, weil
- Es gibt eine schnelle Übersicht, welche Files betroffen sind. Einfacher Knopfdruck für Viewdiff. Man kann schnell auswählen, bei welchen Files ggf. gleiche Einträge überhaupt notwendig sind. Nicht bei allen geänderten.
- Mit den Files, die keine wesentlichen Änderungen enthalten sondern nur Anpassungen an Änderungen anderer Files, braucht man sich also gar nicht beschäftigen.
- Die Änderung im File eingetragen und per Zwischenablage auch im Commit-Text abgelegt ist dann eigentlich nur einmaliger Aufwand, nicht zweimal.
- Wenn es wesentliche Änderungen sind, dann ist die Beschreibung der Änderung auch ein schöpferischer und nicht formeller Akt. Dann lohnt es sich auch, die entsprechend notwendige Zeit aufzubringen. Möglicherweise wird man bei der Änderungsbeschreibung im File auch noch weitere dabei entdeckte Pflegekorrekturen anbringen, die insgesamt die Quelle weiter aufwerten. Dann hat es sich sowieso gelohnt.
Source Content Management oder hart archivieren?
Eine harte Archivierung ist das Verpacken der Files auf einem Datenträger. Da das Zip-format sich als langjährig beständig erwiesen hat, kann man ganze File-Bäume zippen und irgendwo aufheben.
Nachteil: Keine Unterstützung für Diff-View außer auspacken und mit einem Diff-tool vergleichen. Der Total-Commander eignet sich dazu allerdings recht gut, da er in beiden Paneelen in zip-Archive tief eintauchen kann.
Vorteil: Unabhängig von einem Tool, die Files einer Version sind zusammengebunden einfach da. Es hat sich schon oft als günstig erwiesen, lange Jahre zurückliegende Files nicht mit den damaligen Tools aufrollen zu müssen sondern einfach entzippen.
Der Vorteil für die Langjährigkeit sollte bedacht werden.
=>Schlussfolgerung: Ab und zu zippen und wegpacken, mindestens bei wichtigen Releaseständen. Aber unnütze zipfiles auch mal löschen.
=>Schlussfolgerung: Für akutelle Softwareentwicklung jedenfalls ein Source-Integrity-Tool nutzen, Zippen nur zusätzlich.
Verzeichnissstuktur-Rückschluss
Sowohl für das Zippen als auch für Sourcenpflege, Sourcenaustausch usw. liegt der tatsächliche Umfang von Sources insgesamt meist in einem Bereich von wenigen Megabyte. Damit ist der Datenaustausch mindestens erleichtert. Wenn man in die selbe Verzeichnisstruktur in der Quellen liegen noch hineintue:
- Objects
- erzeugte executable und umfangreiche Datenbasis-Files (Visual Studio ncb-Files und dergleichen)
- logfiles, Output-Files beim Testen
- alte Archive (zips)
dann springt der Umfang des Verzeichnisbausms von wenigen Megabyte ganz schnell auf -zig Megabyte. Das Problem merkt man
- beim zippen (ganz schnell mal ablegen zum späteren Vergleich)
- beim Vergleichen (alle Obj erscheinen als geändert, alles rot, erst mal schaun was das ist)
- bei der Pflege der Sources in einem SM-system (Source Management): viele nicht erfasste files: Sind die wichtig? Ach, sind nur Obj, doch ein wichtige wird übersehen.
=>Schlussfolgerung: Möglichst Sources von Testfiles und Executables trennen. Die wenigen Files, die nicht trennbar sind (weil die Tools sie ins aktuelle Verzeichnis legen), in einer ignore-Liste erfassen, ggf. beim zippen ausschließen usw. Sind es wenige, dann sind sie verwaltbar
- Object-Files auf einem tmp-Ordner speichern
- Generierergebnisse neben dem Source-Baum speichern.
Archivieren von Executables
Aus oben genannten Gründen sollten die Libs und Executables nicht mit den Sources im SM gemischt werden.
- Die libs und executables könnten einerseits immer aus den Sources generiert werden (wenn alles richtig ist)
- Die libs und executables sind nicht vergleichbar mit üblichen diffs.
- Die libs und executables sind im Code-Umfang zu hoch.
Es ist aber wichtig, libs und exe im Zusammenhang mit einem Checkpoint der Sources zu speichern.
- Als Auslieferungsstand
- Als wichtigen Teststand für Rückrüsten, möglicherweise ein Kandidat für Auslieferung.
Lösung:
- Beim committen eines guten Standes, der angetestet ist, ein kleines batch laufen lassen, das die exes lokal kopiert mit Datumskennzeichnung.
- Damit sind mehrere exes mit Datumsverbindung zum commit lokal vorhanden. Es kann getestet werden.
- Auslieferung: Executables und ggf. libs als zip abspeichern,, siehe oben. Dabei auf den Stand zugreifen, der vorher lokal kopiert wurde und garantiert aus den Sources, die committed wurden, erstellt wurde.
- Nur bei Master-Releases, die entgültig ausgeliefert werden, sollte folgeder Aufwand getrieben werden: Nach erfolgreichem Test die Quellen auf Produktgenerierungsrechner von anderer Person auschecken, neu compilieren, neues Generat erstellen und nochmals testen. Diese Vorgehensweise sichert die Konsistenz der Quellen mit dem Generat und dürfte bei Auslieferungen wichtig sein, dauert aber in der täglichen Fortschrittsarbeit einfach zu lange.
Mehrere Repositories für ein Produkt
@ident=multiBzr
- Produkt aus mehreren Quell-Komponenten
- Produkt (Executable etc.) besteht aus Quellen aus mehreren Projekten (Komponenten).
Die Quell-Komponenten sind relativ unabhängig und werden an anderer Stelle aus anderen Zusammenhängen ebenfalls gepflegt.
- Schlussfolgerung: Nicht mischen, weil sonst kein Durchblick wo was gepflegt wird.
Jede Quell-Komponente wird in ihrem eigenem .bzr-repository gepflegt.
- Quell-Komponenten befinden sich im Produkt-Sourcenbaum in jeweils bestimmten Unterverzeichnissen
- Unterverzeichnisordnung ist zweckmäßig, weil damit auch im Produkt-Verzeichnis ordnung herrscht.
- In linux kann dort ein symbolischer Link stehen, d.h. Quellen stehen eigentlich ganz woanders. In Windows ist eine Kopie der Komponenten-Quellen im Produkt-Verzeichnisbaum vorhanden.
- In windows kann aber auch ggf. eine Quellkomponente auch ganz woanders stehen, beispielsweise kann bei Eclipse ein Verzeichnis mit absolutem Pfad von irgendwo dem Projkekt hinzugefügt werden. Das ganze ist eine Sache von Pfaden, die irgendwo definiert sein müssen.
- Schlussfolgerung: Das .bzr-Repository der Quellen der Komponente sollte in dem Unterverzeichnis stehen.
- Folglich hängt der Name des Unterverzeichnisses nicht an der Quellkomponente, kann im Produkt auch beliebig gewählt werden. Folglich kann die Quellkomponente auch irgendwo anders stehen, also kein Unterverzeichnis sondern absoluter Pfad. Der absolute Pfad wird beim editieren/generieren beachtet.
Das spricht insgesamt dafür, ein Produkt aus mehreren Bazaar-Quell-Repositories zusammenzusetzen.
Verzeichnisstrukturen
- Grundsätzlich Quellen von Produkten trennen
Zentrale Ablage für Repositories
@ident=centralRepos
Man kann immer und überall Repositories haben. Behält man den überblick und synchronisiert diese gegenseitig (push, pull), dann gibt es auch nicht zuviele Seitenzweige.
Jedoch, arbeiten viele Leute mit den Repositories, auch weniger eingeweihte, einfache Nutzer, anderes Problem Archivierung, langjähriges aufheben: Dann sollte an einer definierten Stelle das Master-Repository stehen. Jeder Quellenbearbeiter hat die Pflicht, sich mit dem Master-Repository abzustimmen, also seine Änderungen zu pushen oder von dort zu pullen. Gegebenenfalls sollte eine Person mit der Pflege des Master-Repositories beauftragt sein. Mindestens bei Releaseständen muss diese Person dort bereinigend eingreifen.
Branches und dessen Auflösung
@ident=.branch
- Viele Seitenzweige wegen unterschiedlichen Korrekturen
- Man kann sich auf den Standpunkt stellen, bei Korrekturen für kundenrelevante Software jeweils nur das aufgetretene Fehlerbild zu behandeln, alle anderen Softwareteile unverändert zu lassen. (Do not touch a running system). Das ist eine weit verbreitete Vorgehensweise. Folge sind dann sehr viele Seitezweige, die kaum mehr zusammenfließen.
- Primär ist diese Vorgehensweise richtig.
- Es zeigt sich aber, dass eine Änderung in Quellen, auch Restrukturierung, häufig zwar Nacharbeiten erforderlich macht. Diese Nacharbeiten sind aber formal abhandelbar. Man braucht nicht an jeder Stelle einer notwendigen Adaption an geänderte Quellenstände nachzudenken sondern muss nur den Compiler befragen. Kommt keine Fehlermeldung, ist alles in Ordnung. Eine Fehlermeldung soll mit formellen anschauen von Aufrufargumenttypen usw. behebbar sein, ohne dass man in die eigentliche Funktionalität einsteigt. Ist eine solche Nacharbeit möglich, dann kostet diese nur die Zeit der Pflege der Quellen, keine extra Testzeit. Zudem kann die Quellenpflege von jemanden ausgeführt werden, der zwar sehr gute Kenntnisse von Quellen und COmpiler hat, aber keine Tiefenkenntnis für die jeweilige Anwendung haben braucht. Man kann also delegieren.
- In diesem Sinn ist eine Adaption eines Produktes an veränderte Quellen der Komponenten möglich und zweckmäßig. Mann kann dann eher an einem Hauptzweig arbeiten.
- Schlussfolgerung: Schnelle Änderungen ->Seitenzweig, Auflösen dessen, Änderung in Hauptzweig einfließen lassen und Adaption des Produktes auf Hautpzweig der Komponenten ausführen.
