Java4c - User contributions [en]

Main Page

JcHartmut — Sun, 18 Nov 2012 20:59:50 GMT

JcHartmut: /* Source Version Management */

This site holds information about programming for embedded software in an ObjectOriented style. Ideas and concepts of the Java programming language are integrated in this thinks. Some articles describe software-engineering-topics.

==Base links==
* [[Java4C]] - why Java-thinking and Java-using for the C-programming
* [[CRuntimeJavalike]] - A base library for embedded C-software
* [[Java2C]] - A translator from Java-sources to C-sources
* [[Component]] - Building the application with components and moduls
* [[Bazaar]] - A Source Version System

==Java4C==
* [[Java4C]] - why Java-thinking and Java-using for the C-programming
* [[SourceLinesAndDocu]] - Graphic programming (UML or other) or '''lines of code''' - what is with the documentation
* [[GraphicAndCodeGen]] - Graphical programming and code generation

==CRuntimeJavalike==
* [[CRuntimeJavalike]] - A base library for embedded C-software
===OSAL===
* [[OSAL]] - The interface to the operation system with its application layer
* basics: [[os_types_def]] // [[os_AtomicAccess]] // [[os_error]]
* somethings: [[os_mem]] // [[os_time]] // [[os_file]] // [[os_endian]]
* MultiThreading: [[os_thread]] -- [[os_waitnotify]] -- [[os_sync]] -- [[os_socket]]
* [[os_Shared_Memory]] -- [[Dual port RAM]] -- [[InterProcessCommunication]]
* [[os_driver]] operation access at driver level

==Java2C==
* [[http://www.vishia.org/Java2C www.vishia.org/Java2C]]
* [[http://sourceforge.net/projects/java2c Java2C on sourceforge]]

==Components, Dependencies==
* [[Component]] - Building the application with components and modules - common description

===Components of vishia-Software===
* [[Components of vishia-Java]] - presentation of components from all Java - sources of org/vishia
* [[Components of CRuntimeJavalike]] - presentation of components from C-sources

===Dependencies===
* [[Dependency]]

====Dependency-Topics of C====
* [[forward declaration of struct]]
* [[forward declaration of functions in header]]

====Dependency-Topics of ObjectOrientation (Java, C)====

* TODO

==Source Version Management==
* [[Source-Version-Management-de]] (german)
* [[Source-Version-Management-en]] (english)
* [[Multi-Bazaar-Components]]: Applications build with independent components with its independent bazaar archives.
* [[Bazaar]] - A Source Version System
* [[Bazaar-Notes]]: discussion (german) about Source-Management and directory structures

==Linux==
* [[Linux]] - Some hints for Linux usage

==The key author of this site==

has experience in embedded programming since 1977, beginning with Assembler programming with the Z80-processor. I'm working for a company in germany in themes of embedded control. This site presents experiences independently of concretely job definitions. Hartmut Schorrig, [[http://www.vishia.org www.vishia.org]]

==The mission of this site - Your contribution==

Exchange of experiences. You can take place on discussion. You can complement the text of the pages with your experience and knowledge. You can improve the appearance of the text.

It is necessary to register with a user name to this site.

Future: [[Inspector datagram]]

Multi-Bazaar-Components

JcHartmut — Sun, 18 Nov 2012 20:58:36 GMT

JcHartmut: bzrGetCmpn

==Navigation==
* up: [[Main_Page#Source_Version_Management]]
* sibling: [[Source-Version-Management-de]] (in german)
* sibling: [[Source-Version-Management-en]]
* sibling: [[Bazaar-Notes]] (german mostly)

==Software assembled with components with more as one bazaar repository==

A software application should consist of more as one component. Each component should be able to describe, program and test independent of the application which uses it. A component may be able to use in several applications. Then it is reuseable. See [[Component]].

One component should have its own [[Source-Version-Management-en]]. Using bazaar, it means it has its own <code>.bzr</code> archive. Any application should use the same Bazaar-Component-Archive. Usual it may be any shared repository (child repository) which have one or more parents or siblings, but they are resynchronized together.

==>Conclusion: Do not mix sources, separate it. Therefore any component needs its own bzr archive.

===Folder structure of the applications working area===

The sources and some help files are located in a working area. If there are components of the application, each component should have its own sub directory. Note that the usage of symbolic linked directories on Unix/Linux or Windows-7 systems supports the possibility to have central working areas for components.

MyApplication
|
+-.bzr archive for the application
+-.bzrignore
+-common organization files
+-special sources of the application
+-Components_directory, may be a symbolic link
| +-.bzr the components bazaar archive
| |-Its_soruces
|
+-Other_Components_directory
+-.bzr the components bazaar archive
|-Its_soruces

The Directory of the application should contain its <code>.bzr</code>-Archive, which does not contain the sources of the components. The <code>.bzrignore</code>-File should exclude the components sub directories.

The components sub directories have its own <code>.bzr</code>-Archive.

===How to ensure the correct revision of the components===

If the Application is resynchronized from a bazaar parent archive using <code>bzr branch</code> or <code>bzr checkout</code> to a new working area, the components are not resynchronized automatically. It should be done from its parent archive, which can be taken from any other source. Because the applications bazaar checkpoint does not contain the components, it has not any information about their correct revision automatically.

To ensure the correct revision of the components, a simple batch/script file per component is located in the applications root directory. That file is contained in the applications bazaar archive of course:

MyApplication
|
+-.bzr archive for the application
+...
+-_bzrGetCmpn_ComponentA.bat
+-_bzrGetCmpn_ComponentB.bat

That files are batchfiles for windows and a shell script for Linux twice. They contain one line:

The batch file contains the simple line:

bzrGetCmpn ComponentA 59 checkout

This line is kept simple and independent of any operation system. Note, that the batchfile works under linux too, if it is set 'executable'. The batchfile calls another script, 'bzrGetCmpn' and names the storing directory and the requested version.

The '''bzrGetCmpn''' scriptfile should be located anywhere in the PATH of the computer. It can be held simple derived from the template in the chapter below [[#The_scriptfile_bzrGetCmpn]]. In that file the location of all parent bazaar repositories should be controlled.

The <code>59</code> is the revision number. You can use a revision string too, see <code>bzr help revisionspec</code>. That revision identifier should be adjusted on any commit on a component. If changed sources of components are committed firstly, and the revision identification is adjusted therewith, a commit to the applications bazaar will be store the adjusted files. In that case a resynchronize of the application will be resynchronizing the components correct revision.

You can start that batch files to get the components files with or without a bazaar repository. You can organize a manual branch via any GUI operations or simple bzr command line calls too. The revision you need do you see in that batch file.

==The scriptfile bzrGetCmpn==

This scriptfile should be exist in the PATH of that computer were the working area of the application is located. Depending on Linux or windows it is different. Some things should be adjusted based on this template.

The following template is for windows systems. The file is named <code>bzrGetCmpn.bat</code>.

@echo off
if not "%1"=="" goto start
:help
echo How to get a component's sources:
echo The sources are contained in an bzr archive. The bzr archive may be an distributed repository.
echo An archive can exist as a copy on several places,
echo for example at an external hard disk or in network or as a local copy in another drive.
echo This batchfile either exports the files from the bzr archiv or it creates a child archiv.
echo If a child archiv was created, changes on files can be committed to the child and merged later with the parent.
echo
echo This batchfile renames an existing location NAME to NAME.old. If it fails, an error message is given.
echo An existing NAME.old will be deleteted.
echo It creates a new location NAME on the current directory always.
echo
echo The batchfile have to be started on the destination location.
echo invkoke: bzrGetVersion NAME [REV] [CHECKOUT]
echo
echo NAME of the archiv in the central location and name of the subdir on current dir
echo REV the revision
echo CHECKOUT if set then an child archiv will be created with bzr checkout, if missing then a file export will be done.
pause
goto :ende
:start
set NAME=%1
if not "%2" == "" set REV=-r %2
set CHECKOUT=%3
::
rem This is the path to all archives for this computer, correct it if necessary:
if "%BZR_ARCHIVEPATH%" == "" set BZR_ARCHIVEPATH=D:\Bzr
::
echo The batch renames the current directory if it is existing yet:
if not exist %NAME% goto :noCurrent
if exist %NAME%.old rmdir /S/Q %NAME%.old
if exist %NAME%.old goto :nodelOld
ren %NAME% %NAME%.old
if exist %NAME% goto :noRename
:noCurrent
::
echo copy the bzr archive and resynchronize all members with the required revision
if "%CHECKOUT%"=="" goto :export
echo on
call bzr checkout %BZR_ARCHIVEPATH%/%NAME% %NAME% %REV%
@echo on
call bzr log -n5 %REV% >%NAME%\_bzr_lastversions.txt
@echo off
goto :okresync

:export
set DIR=%CD%
cd /D %BZR_ARCHIVEPATH%\%NAME%
echo on
call bzr export %DIR%\%NAME% %REV% --per-file-timestamps
@echo on
call bzr log -n5 %REV% >%DIR%\%NAME%\_bzr_lastversions.txt
@echo off
::pause
cd /D %DIR%
:okresync
if not exist %NAME% goto :noBzr
goto :ende
::
:noRename
echo can't rename %NAME% to %NAME%.old. It may be used yet. Do it manually!
pause
goto :ende
::
:nodelOld
echo can't delete %NAME%.old. It may be used yet. Do it manually!
pause
goto :ende
::
:noBzr
echo The bzr archive is not pulled. The version may be faulty or the source path of bzr does not exist.
echo See error messages above.
pause
:ende
exit /B

If you follow the command statements, you can see that an existing directory is kept, of found, but the directory of the component is get newly anytime. It assumes that all bzr archives are located in one directory in the file tree, which can be an external disk too or an network path. See 'BZR_ARCHIVEPATH'.

The content of the archive will be cloned with the 'bzr checkout' command. The files are resynchronized therefore. An independent working with the files and the cloned archive is possible, if necessary. The working can be pushed to its parent later using 'bzr push', 'bzr merge' etc. But in most cases only the resynchronized version of files are need.

Source-Version-Management-en

JcHartmut — Sun, 18 Nov 2012 20:52:47 GMT

JcHartmut: The chapter 'More as one Repository for one product' is contained now in the linked page.

==Source code management (SCM)==
@ident=SCM-en

Links:
* [[Multi-Bazaar-Components]]: More as one Repository for one product.
* [[Bazaar-guide]]: a guide to use Bazaar.

This size is the english version

==Zentrale Ablage für Repositories==
@ident=SCM-centralRepos-de

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.

===Creating one shared repository in the local space===
The ''local space'' means any external hard disk, network folder or such which is owned by one person, by me. It is my local space, which can be used from some more people in my direct environment.

For any component of sources one shared repository should be created one time. On one sub directory per component: ''bzre: Bazaar -> Start -> Initialize: (x) Shared repository''. An existing plain branch can be pushed to them.

===Creating a branch for working===

* Create a new plain branch at the working position: ''bzre: Bazaar -> Start -> Initialize: (x) Plain branch''.
* Pull from a shared repositiory: ''Button Pull, select the shared repository, select a branch.
** If there are some files already, create the branch at a new position and then move .bzr subdir.

==Branches und dessen Auflösung==
@ident=SCM-sidebranch-en

;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.

===Side branches===
less experience

bzr checkout ../masterlocation . -r REVNR

Gets a part of trunk untio REVNR. It is similar

bzr revert -r REVNR

What is the difference???

bzr update ../masterlocation .

This copies all files in the current dir. It seems to destroy the older-revision side branch (?)

Is there a possibility to checkin changes based on a older revision, without any merge. Only the changed files based on the older revision should be stored in the bazaar repositiory - to compare with other versions or look for changes later. Background: Changing of some source files to bugfix an older software. The reason is not develop and merge.

The workflow of develop and bugfix in a decentralized team is explained in
* [[http://doc.bazaar.canonical.com/latest/en/user-guide/organizing_branches.html doc.bazaar.canonical.com/latest/en/user-guide/organizing_branches]].

But this is not the problem of side branches, more the problem of development in team.

'''An side glance to git''':

$ git branch bugfix

creates a branch named 'bugfix' in the same only one repository. It is a branch with the same revision as the current one.

$ git checkout bugfix
now switches to the named branch.

$ git reset -q COMMITNR

This moves the current revision of the current branch (it is 'bugfix' to a older revision. COMMITNR is the hash number of any commit, see git log

$ git checkout .

resynchronized all files of the selected revision.

...changing any files and

$ git commit

builds a side branch in the repository (archive).

Now a switch to another branch and its revision is possible in the same sandbox to work with it:

$ git checkout master

now switches back to this named branch and resynchronizes all files. Work with it, commit etc.

If there should be worked only at one side branch to any time, and be worked at another side branch to another time, then only one sandbox is necessary. You can switch between the branches. The files are changed, all files are stored in the git archive.

If there should be worked with more as one side branches to the same time, a copy of the git archive is necessary. The archive and the files should be stored at different places on the hard disk, or at more as one computer etc. It isn't recommended to use the same git archive, may be with an symbolic link in linux. The disadvantage is: The git archive knows the current branch, which was selected with 'checkout'. If you want to use only one archive but more as one sandbox for the files, you can have a symbolic link in the sandboxes to the same archive. But then you have to switch between the side-branches before any status, commit etc. action are done in one of the sandboxes. But be attentive to your files. You may overwrite they if you are careless. You can't do that at the same time, maybe more as one people in network. It will be confused if they are work concurrently.

I haven't test yet, but it shouldn't a problem to merge the more as one git archives without conflicts, if only one archive has changed only one side branch.

[[http://www.vishia.org/SwEng/pictures/git-side-branch-example.jpg Image: example side branches in git]]

'''Now back to bazaar''':

John A Meinel proposed the following answer:

If you want to commit new changes based on an older revision, you generally want to start a new branch. So something like

bzr branch master feature -r OLD
cd feature
bzr commit

If you are using a checkout you can do

cd checkout
bzr branch --switch -r OLD ../master ../feature

TODO test

====Experience with large project====

* Created a side branch in another directory with
bzr branch VersionNr.

* Work, work, work, supply to customer.

* Now I want to merge most of changes on the old side branch to the actual version.

* Using Bzr-Explorer. Inside the trunk (the original tree from which the side branch was taken) press the ''merge'' button,
give the path to the side branch directory where .bzr is found. It is equal to the command:

bzr merge pathToSideBranch

* Now it shows 14 Conflicts,
* The files which are not changed from base revision to actual, but changed in side, are taken from side without further enquiry.
* The files which are changed from base to actual, and also changed in side, are stored with extension
** .BASE the common base version
** .OTHER the side branch which is merged into
** .THIS the actual version in this sandbox.
* The current file without extensions is pre-merged. If changes are detect between BASE and OTHER wich are not changed between BASE and THIS,
or if changes are detect between BASE and THIS which are not changed between BASE and OTHER, both are present in the pre-merged current file.
It is able to presume that both changes are relevant.
* But if the changes at the equal position are conflictin between BASE and THIS and BASE and OTHER, then a labeling is done in the form:

>>>>>>TREE
the = code + in + this;
======
the = code + in + other;
<<<<<<MERGE
* This parts of changes should be visualized and adjusted manually.
* It may be recommended to compare all changes accurately. Use a diff tool and compare the actual file with file.THIS, file.OTHER.
For this action I use The.file.Commander with a pre-written command to call

==diff THIS==
&dj.bat <*absFile1> <*absFile1>.THIS

==diff OTHER==
&dj.bat <*absFile1> <*absFile1>.OTHER

==diff BASE==
&dj.bat <*absFile1> <*absFile1>.BASE

==diff OTH_BASE==
&dj.bat <*absFile1>.OTHER <*absFile1>.BASE

==diff THIS_BASE==
&dj.bat <*absFile1>.THIS <*absFile1>.BASE

*+ where ''dj.bat'' is a command file to call a diff-view tool.

* declaring the conflicts are resolved with command (in bzr-explorer)

bzr resolve --all

* Press refresh firt in GUI, because it is a manual command, then the conflicts are not shown any more.

* now commit all changes.

Source-Version-Management-de

JcHartmut — Sun, 18 Nov 2012 19:47:00 GMT

JcHartmut: /* Navigation */

==Navigation==
* up: [[Main_Page]]
* sibling: [[Source-Version-Management-en]]
* sibling: [[Bazaar-Notes]] (german mostly)
* sibling: [[Multi-Bazaar-Components]] Software assembled with components with more as one bazaar repository
* down: TODO some examples and pattern

==Source code management (SCM)==
@ident=SCM

Links local:
* [[Bazaar-guide|Bazaar-guide]]: a guide to use Bazaar.

Links in www:
* [[http://wiki.bazaar.canonical.com/Scenarios|wiki.bazaar.canonical.com/Scenarios]]: wiki.bazaar.canonical.com/Scenarios

This size is in german, because it is discussed in a german team. It will be presented in english in the future. TODO

==Kurzer Abriss, Arbeit mit MKSSI, git, mercurial, Bazaar==
@ident=SCM-gitCo

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 [[https://bitbucket.org/jchartmut/cruntimejavalike 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.

==Einzelne Files vs. SCM-Archiv==
@ident=SCM-Files
.
===Primat der Datenhaltung im SCM===

Ein Source Content Management (SCM) wie Bazaar, git oder andere enthält alle relevanten Files einschließlich deren Versionierung in einer eigenen internen Form (Datenbasis) gespeichert. Dem gegenüber steht der ''Working tree''. Das sind die Files mit denen man arbeitet. Der ''working tree'' lässt sich jederzeit aus dem SCM für beliebige Versionen rekonstruieren. Committet man immer auch Änderungen, dann ist der ''working tree'' temporär. Man braucht ihn nur während des Editierens, Compilierens, Makens. Danach kann er ersatzlos gelöscht werden, da alles im Archiv des SCM steht.

Damit steht das SCM im Mittelpunkt. Das ist auch in Ordnung so, da dies die entscheidende Stelle für die Versionierung der Sources ist. Diesbezüglich unterscheiden sich zentrale SCM nicht von den verteilten. Lediglich - bei einem zentralem SCM braucht man die Serveranbindung.

Die Files stehen meist als ''working tree'' solange bereit, bis man sie nach vorigem ''commit'' oder ''checkin'' löscht. Damit kann man auch bei einem zentralem SCM dezentral an den Files arbeiten, wenn auch nicht einchecken oder ältere Versionen sichten.

Die Alternative, ein File-Baum nur in direkter Verbindung mit dem SCM bereitzustellen gibt es auch. Dann sind die Files nur aufrufbar, wenn das SCM läuft. Die Files werden vom Betriebssystem dann nicht auf der Festplatte mit dem üblichen Filesystem gespeichert sondern alle Filezugriffe des Betriebssystems laufen über den SCM-Treiber. Damit sind keine Files vorhanden wenn das SCM mit seinem Archiv nicht zugänglich ist. Diese Variante ist die konsequenteste Anbindung an ein SCM, aber für eine offline-Arbeit eher schwierig und daher weniger verbreitet.

Es gibt also ein '''Primat des SCM gegenüber den Einzelfiles''', das mehr oder weniger stark ist.

===Gegenentwurf - Primat der Einzelfiles, lediglich Ablage und Austausch über das SCM===

Es ist möglich, die Hauptsicht auf die Files zu legen und das SCM nur als ''Ablage'' oder Austauschmedium zu nutzen. Die Files werden dann immer beibehalten, in das SCM wird nur eingecheckt oder committet. Das SCM hat dann den Zweck, auf Altversionen rückgreifen zu können und Versionen einfach zu vergleichen. Austauschen wird man gegebenenfalls über das SCM nur bestimmte Schnittstellenfiles, wenn die Bearbeitung sonst in einer Hand liegt.

Diese Arbeitsweise hat einen entscheidenden Nachteil: Es wird gegebenenfalls nicht bemerkt, dass wichtige Files überhaupt nicht in das SCM aufgenommen worden sind. Wenn dann keine weitere Datensicherung besteht und nur noch der Datengehalt des SCM verfügbar ist, sei es wegen einem Hardwarecrash, sei es bei Bearbeiterwechsel usw, dann kommt das Böse Erwachen. Es compiliert nicht, was fehlt...

Der andere Nachteil ist, das sich möglicherweise Alt-Files ansammeln, man löscht diese nicht aus Befürchtung, irgendwo könnten diese noch wichtig sein.

Tendiert ein Bearbeiter zu der Arbeitsweise, eher Files zu behalten und nur einzuchecken, dann muss es einen Test an anderer Stelle auf Vollständigkeit der Daten im SCM geben. Am einfachsten ist dies getan, wenn auf einem leerem PC oder Verzeichnisbaum aus dem SCM ausgecheckt wird und dort alle relevanten Makeprozesse durchlaufen werden. Laufen diese fehlerfrei und ist das Ergebnis korrekt, dann sind die Sources vollständig.

===Kompromiss - Arbeit mit Files und dem SCM===

Eine kleine Anekdote:

Seit mehr als einem Jahrzehnt läuft Software auf Anlagen. Sorry, die Welt ist nicht so schnellebig wie junge Leute heute glauben. Die Software wurde zu einer Zeit erstellt (seit 1994), zu der SCM noch nicht so gängige Praxis war. Jedoch wurde die Software in fleißiger Arbeit postum eingecheckt, prozess-konform, wie es sich ordentlich gehört. - Ein paar Jahre später, Nachbesserung von Hardware auf der Anlage, gegebenenfalls ist die Software betroffen. Mittlerweile war das SCM die "alte Version", doch selbstverständlich, man hat ja Zugänge und Archive gespeichert. 1 Tag Arbeit, und der Zugang funktioniert. Nun jedoch zeigte es sich, das zwar damals alles ordentlich eingecheckt wurde, aber nur die offensichtlichen Endstände. Da fehlte etwas, da stimmt was nicht - da war doch noch was ????. Bis ein Kollege damit herausrückte, er hat mal alle Stände auf CD direkt archiviert, die CD liegt im Schrank.

Die Files auf der CD hatten dann tatsächlich für mich als Entwickler einen hohen Wiedererkennungswert, wichtig dabei die Verzeichnisstruktur. Da die Backups von den laufenden Arbeitsstadionen gezogen worden sind, direkt ohne Zusatzaufwand als Filebaum, war eine Vollständigkeit gewährleistet. Die Zusatzarbeit des Eincheckens in das damalige SCM versionsgetreu hatte also Informationen verwässert.

Mit Diff-View auf den Files war dann schnell wieder der Überblick über den Gang der Entwicklung da. Übrigens - wenn man alles sehr fein säuberlich dokumentiert, auf 100 Seiten oder mehr, muss man dann später die 134 Seiten wieder lesen - ist auch Aufwand.

==>Über lange Jahre ist zwar ein SCM-System stabil und kritikunwürdig (ja klar), aber die Arbeit damit nicht. Zum Glück hat man dann backups der Files direkt.

==>Ein SCM ist wichtig für die zeitnahe Arbeit. Insbesondere für das Diff-View und die Nachverfolgung, wann wurde was geändert. Ohne SCM ist nicht!!! Aber die Arbeit direkt mit den Files hat auch seine Vorteile.

==Mehrere Arbeitsverzeichnisse, mehrere SCM-Archive, Wiederverwendung==

Wird Software stark wiederverwendet, dann erscheinen die gleichen Quellfiles möglicherweise innerhalb der jeweiligen Applikationen selbst beim selben Bearbeiter mehrfach.

Diese konsequente Art der Wiederverwendung ist nicht häufig anzutreffen. Wiederverwendung wird meist verstanden als ''kopiere es und pass es an''. Die konsequente Wiederverwendung - gleiche Quellen ohne Anpassung - hat den Vorteil dass Fehler oder Verbesserungen in einer Anwendung gefunden sofort auch in den anderen Anwendungen nützen. Allerdings muss man bei diesen wiederverwendeten Quellen die Unabhängigkeit von der jeweiligen Applikation beachten. Eigentlich eine konsequente Softwaretechnologie.

Werden die Quellen mehrfach für verschiedene Applikationen benutzt, dann kann nicht vorausgesetzt werden, dass alle Projekte mit einem einheitlichen Stand der Quellen arbeiten. Wünschenswert ist es zwar, dass an allen Stellen mit der selben Version gearbeitet wird, eben wegen der Vorteile. Andererseits kann aber eine Änderung in einer Applikation zwar allgemeingültig erfolgen, jedoch nicht fehlerfrei und allgemeingültig genug. In einer anderen Applikation können sich Folgefehler ergeben, die erst gefunden und getestet werden müssen. Ergebnis dessen ist zwar eine verbesserte Allgemeingültigkeit, jedoch ist dies mit Arbeit verbunden. Für Bugfixes aus Sicht einer Anwendung werden sich daher Differenzen nicht vermeiden lassen.

Damit sind möglicherweise Seitenzweige im Archiv des SCM erforderlich. Andererseits sollte ein Zuviel an Seitenzweigen vermieden werden, besser ist es jeweils nach Korrekturen den Hauptzweig anzuwenden. Die Seitenzweige sollten eher temporärer Natur sein.

Das SCM Bazaar unterstützt Seitenzweige mit automatisch unterstütztem merge.

===Vermeiden von Seitenzweigen bei Änderungen gemeinsamer Quellen für verschiedene Anwendungen zeitlich nacheinander===

Um Seitenzweige zu vermeiden, kann sich folgende Vorgehensweise als geeignet erweisen:

* Angenommen, eine Applikation A verwendet die Hauptversion 123.

* In einer anderen Applikation B werden in einer gemeinsamen Source-Komponente Verbesserungen vorgenommen. Damit entsteht letzlich die Hauptverson 137.

* Nun wird versucht, die Hauptversion 137 auch in A anzuwenden. Angenommen, es gibt Anpassungsnotwendigkeiten, die sich erst aus Sicht der Applikation A zeigen aber insgesamt die gemeinsame Komponente aufwerten. Es entsteht Hauptversion 139.

* Nun sollte diese Hauptversion auch für B anwendbar sein. Hat man Schnittstellen gut definiert, dann sollte es nicht unbedingt schon wieder Komplikationen geben. Es bleibt also bei der 139.

* Das Ganze soll nun auch für weitere Applikationen passen. Eventuell sind wiederum Anpassarbeiten notwendig.

Werden die Anpassungen nicht nacheinander sondern parallel ausgeführt, von verschiedenen Bearbeitern, dann entstehen zwischendurch Seitenzweige, die jeweils wieder bereinigt werden müssen. Diese Bereinigungen sind teils mergen, teils Schnittstellen klarer formulieren, teils Verbesserungen für allgemeingültige Verwendung. Es ist nun günstig, diese Bereinigungen in einer Referenzapplikation zentralisiert auszuführen. Der Test, ob die Ergebnisse bei den einzelnen Applikationen passt, ist dann wieder dezentralisiert.

Verwendet man Bazaar, dann entstehen dezentralisiert divergierende Versionen. Diese in einem Baum zusammenzufassen kann sich gegebenenfalls als nicht zweckmäßig erweisen. Gegebenenfalls ist es besser, in der zentralisierten Bearbeitung der Komponente mit der Referenzapplikation zwar alle Inputs zu verwerten, aber nicht auch alle nuancierte Änderungen im Original zu berücksichtigen. Oft ist ein Austausch - eine kompatible aber bessere Variante - die einfache Lösung, die auch Zufriedenheit bei den einzelnen Applikationen auslöst.

Damit ergibt sich allerdings die Situation, dass das formelle Arbeiten mit den Bazaar-Archiven nicht funktioniert. Denn:

* Applikation A hat ihre Version 125 abgegeben (merge-Input), die eine Verbesserung der zuvor erhaltenen (poll) Version 123 darstellt.

* Applikation B hat aber in ihrer Version 137 aus der gemeinsamen Versionen 123 hervorgegangen möglicherweise adäquate aber nicht gleiche Lösungen gefunden, die auch der Verbesserung in A entsprechen.

* Die zentralisierte Bereinigung entschließt sich daher, zwar die Funktionalität von A in 125 in der Nachbearbeitung zu garantieren, enthält aber nicht formell den Versionsstand 125 von A. Die nachbearbeitete Komponente wird also als Version 137 wieder der Applikation A angeboten, jedoch nicht passend in Archivbaum, der in A verwendet wird.

* A muss nun einerseits möglichst positiv entscheiden, dass die Änderungen zu Version 137 überhaupt benutzt werden. Die positive Entscheidung bedeutet die Fortsetzung der Partizipation an der Weiterentwicklung in der Zukunft. Andererseits muss A den Aufwand treiben, zu testen, dass es keine negativen Auswirkungen gibt.

* Formell kann die Applikation A nicht das bisherige SCM-Archiv einfach updaten, da die eigene letzte Version nicht enthalten ist.

* Zielführender ist es, nun auf der Basis der Sichtung der Differenzen der Files zu entscheiden, welche Tests ausgeführt werden müssen und welche Auswirkungen zu erwarten sind. Möglicherweise findet sich die Funktionalität der ursprünglichen Verbesserung 125 in A in nur in wenigen Zeilen nicht identisch aber passend ausgeführt. Alle anderen Änderungen sind nicht relevant da sie nicht verwendete Funktionen betreffen. Es ist also auf Basis der File-Differenz-Sichtung leicht zu entscheiden, dass nunmehr auf der neuen Version 137 aufgesetzt wird.

* Das SCM-Archiv kann nun in der Applikation A neu importiert werden, das alte Archiv wird gelöscht. Es enthielt zwar die Änderungen von 123 auf 125, die sich im neuen Archiv nicht finden, angenommenerweise ist diese Version 125 in A aber nicht pflegerelevant.

Dieses Szenario kann durchaus als typisch bezeichnet werden. Die meisten Änderungen werden kompatibel vorgenommen oder treffen nicht für alle Applikationen zu, wenn sorgsam in der Komponentenentwicklung gearbeitet wird.

Damit verschiebt sich allerdings die '''Sicht vom Primat des SCM-Archivs auf das Primat der Files'''. Zumindestens während des Überganges der Nutzung der neuen Hauptversion 137.

Wie sollte konkret umgegangen werden:

* Die neue Hauptversion 137 der Komponente wird aus dem erhaltenem SCM-Archiv auf einer unabhängigen Stelle im Filesystem als Workingtree exportiert. Die Files der Komponente in der Applikation werden nicht geändert.

* Nun erfolgt der Einzelfilevergleich zwischen dem neuen Workingtree und den bestehenden Files. Selbstverständlich sind dabei die Einträge im Log des SCM-Archives für das Verständnis der Änderungen wichtig. Letzlich werden aber die Inhalte der Files auf Passfähigkeit begutachtet.

* Im zweiten Schritt werden die neuen Files als File, nicht über das SCM-Archiv in die bisherige Applikation kopiert und die im alten aber nicht im neuen Archiv befindliche Files werden gelöscht. Letzteres ist wesentlich und typisch wenn in der Komponente umstrukturiert wurde. Das bisherige Archiv, im Beispiel auf der 125 stehend, wird erstmal weiterverwendet. Der neue Stand wird also als 126 committet.

* Danach erfolgt der Test von A.

* Im Idealfall passt alles. Es gibt keine Änderungen. Etwas weniger ideal aber erwartbar ist, dass der Stand der Komponente 137 vollständig akzeptierbar ist, allerdings sind kleine Nachbesserungen in der Applikation notwendig.

* In diesen beiden Fällen kann dann das Archiv ausgetauscht werden. Das alte SCM-Archiv mit den Versionsständen 123, 125 und zuletzt 126 wird entfernt, statt dessen das gelieferte Archiv mit der 137 eingesetzt. Im Archiv kann dann nachgelesen werden, welche Änderungen es insgesamt in der Komponente gab, auch wenn sich diese nicht aus der Applikation A ergeben hatten. Möglicherweise sind diese Änderungen für die Weiterentwicklung von A interessant oder wichtig.

Der Fall der notwendigen Nachbesserung in der Komponente, weil die Funktionalität in A nicht passt, erfordert den oben beispielhaft dargestellten Zyklus der Nachbesserung in der Komponente mit notwendigem Aufwand wiederum für alle Applikationen. Entweder dieser Aufwand ist gerechtfertigt oder möglich. Oder nach entsprechenden Klärungen ordnet sich die Applikation A dem gegebenen Stand der Komponente unter, oder mindestens vorerst wird weiter mit der eigenen Variante A gefahren.

* Konkret kann dabei auf der neu gelieferten Version 137 mit neuem Archiv aufgesetzt werden: Dort werden die notwendigen Änderungen vorgenommen und das ganze wird als neuer Versionsstand 138 aus Sicht der Applikation A an die zentrale Komponentenentwicklung zurückgeliefert.

* Der Zyklus beginnt damit erneut, hoffentlich mit kleinen und kompatibel ausführbaren Änderungen, die für eine Beruhigung der Zyklen sorgt.

===Überblick über die Anzahl Archive für die selbe Softwarekomponente ?===

Die Kapitelüberschrift ist mit einem Fragezeichen versehen.

Angenommen, es gibt etwa 10+x Stellen, an denen die selbe Softwarekomponente eingesetzt wird. Das kann sich auf mehrere PCs und Bearbeiter verteilen, auch auf dem selben PC mag es mehrere Stellen geben, weil die Softwarekomponente eben in verschiedenen Applikationen drinsteckt.

Bazaar sieht nun vor, an jedem Working tree ein eigenes Archiv zu haben. Man kann mit Bazaar-Bordmitteln dann pushen, pullen, mergen jeweils mit einem anderen Archiv. Insbesondere kann an jedem Archiv auch ein 'submit-branch'' angegeben werden (Settings - configuration - branch). Damit kann unaufwändig ein etwas zentraleres Archiv angesprochen und beobachtet werden.

Dennoch, bei 10+x Archiven, die sich gut gegeneinander updaten lassen, können sich Unterschiede breitmachen und Merge-Aufwand erzeugen, die überhaupt nicht gewünscht sind. Außerdem kann man leicht den Überblick verlieren, wo denn überhaupt welche Bearbeitung stattgefunden hat. Beim Mergen muss man dann erst einmal überlegen, was denn die bessere Version ist. Damit artet das Ganze in Arbeit aus, die man doch vermeiden und verbessern wollte ....

Außerdem kann es passieren, das in den Weiten eines Verzeichnisbaumes die Archive nicht mehr gefunden werden. Man hat also vor ein paar Monaten eine Arbeit fortgesetzt, das Archiv an eine andere Stelle kopiert, dann kamen andere Themen dazwischen. Merkt man sich immer wo man als letztes dran war oder kommt es vor, dass eine Arbeit wegen der eigenen Vergesslichkeit doppelt gemacht wird? Irren ist menschlich, aber eine gute Organisation auf dem Computer sollte Irrtümern vorbeugen.

Die Arbeit mit einem zentralen Archiv gestaltet sich dann einfacher, wenn das es eigentlich nur einen Hauptzweig gibt und Unterschiede vermieden werden sollen. Unterschiede entstehen eigentlich eher unerwünscht bei Parallelarbeiten und sind möglichst schnell wieder abzustellen.

Es soll hier aber nicht den zentralen Archiven das Wort geredet werden. Der Vorteil der dezentralen Archive ist gerade ein gewisses unabhängiges Arbeiten und eine gute Merge-Unterstützung. Jedoch - total denzentral kann auch zuviel des Guten sein.

Zweckdienlich kann es sein, für einen Bearbeiter auf einem PC nur ein Archiv zu halten. Voraussetzung dafür ist aber, das alle Applikationen tatsächlich immer mit den gleichen Source-Versionsstand compiliert werden sollen. Ich habe auf einem PC auch nur eine Entwicklungsumgebung (Eclipse für Java), in der alle Quellen für alle Projekte eingebunden sind. Damit ist es bei Strukturänderungen relativ einfach, die automatischen Möglichkeiten des Tools zu nutzen (renaming, wird automatisch in allen sichtbaren Quellen nachgezogen). Außerdem gewinnt man bei möglicherweise problematisch inkompatiblen Änderungen sofort den Überblick, wo es klemmen könnte. Es wird jeweils alles compiliert. Diese Arbeitsweise hat sich bewährt.

Dennoch, für die einzelnen Applikationen gibt es bei mir verschiedene Stellen im Filesystem (Working area). Wichtig ist, dass eine Änderung eben gerade ausgeführt mit Auswirkungen auf Applikation X zwar formell compilierfähig ist aber damit noch nicht getestet, sich nicht sofort auf einen Auslieferungsstand mit Feinkorrektur auswirkt. An diesen Stellen compiliere ich mit einem Batch-Aufruf. Das ist einfacher. Beim Batch-Aufruf werden die Files in der Working-Area benutzt. Bei einer Feinkorrektur braucht es keinen entwicklungsumgebungsunterstützten Test mit Schritt-Debugging usw. Die Korrektur wird textuell ausgeführt, compiliert und zur Laufzeit getestet.

Ein Gesamttest wird aber in dem zentralem Eclipse-Projekt mit zentralisierten Files. Damit wird immer auf dem letzten Stand basierend getestet. Von dieser zentralisierter Working-Area wird dann das Archiv (Bazaar) gepflegt, von dort wird committed.

Wie kommt aber nun eine Detailänderung aus einer denzentralen Workingarea in das Archiv? Wie kommt der letzte Archivstand in die dezentrale Working-Area?

Für die zweite Frage gäbe es eine Antwort:

bzr export %DST% --per-file-timestamps -r %REVISION%

Damit werden nur Files nach %DST% kopiert, sogar mit dem originalem Datum (geht nicht bei Unix), optional mit einer angegebenen Revisionskennzeichnung. Aber: Das ist ein blindes kopieren. Man sieht nicht vorher, welche Änderungen sich damit ergeben. Man übersieht und überschreibt für immer Änderungen in der Workingarea. "bzr export" eignet sich für die Erstellung einer neuen workingarea ohne Archivanbindung, nicht aber für's updaten.

Die ggf. bessere Variante liegt außerhalb des SCM, nämlich bei den altbewährten '''File-Baum-Diff-Tools'''. Da gibt es eine Menge, jeder hat seine gewohnten Tools, diese haben sich bewährt. Man kann die Unterschiede per File-Vergleich sichten und damit übersichtlich entscheiden, ob eine Änderung denn überhaupt wesentlich ist, was eine andere Änderung an Nebeneffekten bewirken könnte usw. usf. Ein Merge mit bazaar ist zwar auch ganz gut, aber es erzeugt zuerst Seitenversionen, bei denen man im Nachhinein (!) dann feststellt, dass das eigentlich unerwünschte oder unnötige Seitenzweigänderungen sind. Damit sind diese aber schon im Archiv manifestiert, haben Datenmüll erzeugt und müssen dann zusätzlich im Nachhinein wieder ausgebessert werden (Anschauen, löschen von *.THIS, *.BASE und *.OTher). Die Arbeit kann man sich sparen.

Die Lösung wäre also hier: Ein Archiv (pro PC) mit dem Haupt-Workingtree aus Haupt-Workingarea, '''manuelles Abstimmen von Files in den einzelnen Workingareas''' für die jeweiligen Applikationen. Man kann in diesem Zusammenhang "bzr export" nutzen um letzlich genau den Archivstand in eine Applikations-Workingarea hineinzulegen. Zuvor sollte die Workingarea gelöscht bzw. besser parallel gesichert und danach gelöscht werden. Erfolgt das löschen nicht, dann besteht die Gefahr, dass in der Applkations-Workingarea Files liegen, die wichtig für die Applikation sind, sich aber nicht im SCM-Archiv befinden. Das sollte unbedingt kontrolliert und vermieden werden. Wird zuerst per "move"- Befehl gelöscht und gesichert, danach die Files per "bzr export" neu eingespielt und danach compiliert, dann fallen diese Fehler auf. Bei Problemen kann man auf die gesichrten Files zurückgreifen. Letztlich sollte die Sicherung aber vernichtet werden, da sie sonst auch wieder nur Datenmüll ist.

Es gibt noch eine andere Möglichkeit des Bindens nur eines Archives an mehrere Working-Areas:

Unter Linux kann ein symbolischer Link <code>bzr.</code> auf das Archiv gelegt werden. Das Archiv muss dabei auf demselben Datenträger stehen, einige Funktionalitäten in Bazaar gehen sonst nicht. Aber es kann zentral irgendwo anders stehen. Mehrere symbolische Links können auf das selbe Archiv zeigen.

Nun kann man damit
* ''commit'' von verschiedenen Working-Areas ausführen und trifft jeweils das selbe Archiv. Die committeten Files erscheinen damit im Archiv, nicht jedoch automatisch in den anderen Working-Areas!
* den Filebaum betrachten und feststellen, welche Änderungen im Archiv passiert sind, die nicht aus dieser Workingarea stammmen. Man kann sich über die Bazaar-GUI die Differenzen anzeigen. Da Bazaar diese Arbeitsweise so nicht vorsieht, präsentieren sich die Änderungen spielelverkehrt. Geänderte Files mit neuem Stand im Archiv erscheinen als ''commitwürdig'' der alten Files. Neue Files im Archiv erscheinen als ''deleted files''. Um hier zu unterscheiden, was denn Änderungen in der speziellen Working Area sind, muss man schon die eigenen Files kennen. Dabei hilft ein kleines Backup des letzten Standes aus dem SCM, auf dem aufgesetzt worden ist, dabei wieder mit File-Diff-View außerhalb des SCM - nur um die eigenen Änderungen zu erkennen. Das ist damit eindeutig. File-Diff-Tools können teils auch direkt in Zip-Archiven arbeiten. Man benötigt also nur ein einfaches Zip-Backup angelegt bevor man in der speziellen Working area losarbeitet. Man kann auch postum über ein "bzr export" den Ausgangstand wieder erzeugen.
* committen einzelner Files, die nur in dieser Working Area geändert worden sind.
* Zuletzt über

bzr revert

*+den Stand aus dem SCM-Archiv in die working-Area hinein synchronisieren um wieder einen gemeinsamen Ausgangsstand zu haben.

Unter Windows geht das mit dem symbolischen Link nicht. Man kann aber stattdessen mit einem move-Befehl das Archiv von einem Platz auf einen anderen Hin- und Herschieben. Es sollte zuletzt immer auf dem zentralen Platz wieder landen, sonst weiß man nicht wo es aktuell steht. Der <code>move</code>-Befehl kopiert nicht die Archiv-Files auf der Festplatte sondern ändert tatsächlich nur einen Verzeichniseintrag. Das ist also von der Belastung der Festplatte und vom Zeitaufwand her gesehen sehr billig. Vorraussetzung: Selbe Partition der Festplatte!

Ich habe dazu folgende Befehlsfolge in einem zentralen Batch-File niederlegt:

File <code>bzr_mvExpl.bat</code>

set CMPN=%1
REM Add the Bzr directory to system-wide PATH environment variable
SET PATH=D:\Progs\Bazaar;%PATH%
attrib -h \Bzr\%CMPN%\.bzr
if not exist .bzr move \Bzr\%CMPN%\.bzr .bzr
echo Bazaar-Explorer:
bzrw.exe explorer .
bzr.exe version-info >_bzr_version.txt
if not exist \Bzr\%CMPN%\.bzr move .bzr \Bzr\%CMPN%
attrib +h \Bzr\%CMPN%\.bzr

Wichtig für das funktionieren des move-Befehls ist das Rücksetzen des Hidden-Attributes für das .bzr-Archiv.

Dieses File wird in einem File im Arbeitsverzeichnis (Working Area)

.bzr.bat

mit drei Zeilen

SET USERNAME=hartmut
SET BZREMAIL=hartmut.schorrig@vishia.de
bzr_mvExpl.bat srcJava_vishiaBase

aufgerufen. Das <code>srcJava_vishiaBase</code> ist hierbei der Name der Softwarekomponente und der Name des Verzeichnisses in dem das <code>.bzr</code>-Archiv steht. Alle <code>.bzr</code>-Archive stehen dabei zentral auf der selben Festplatte (keine Laufwerksangabe am Pfad) im Verzeichnis <code>\Bzr</code>. Da dies so zentral festgelegt ist, kann das Batchfile direkt darauf zugreifen. Im Start-Batchfile sind zusätzlich in lokal gültigen Umgebugsvariablen die Commit-Daten niedergelegt. Diese sind damit Working-Area-spezifisch.

Es gibt dann noch einen weiteren interessanten Batchfile:

File <code>bzre.bat</code>

@echo off
REM Add the Bzr directory to system-wide PATH environment variable
SET PATH=D:\Progs\Bazaar;%PATH%
SET USERNAME=hartmut
SET BZREMAIL=hartmut.schorrig@vishia.de
::
if not "%1" == "cd" goto :nocd
echo on
cd %2
echo off
:nocd
REM if the directory contains .bzr.bat, it is processed. It doesnt return!
REM if the directory or any parent does not contain .bzr change to the parent.
if exist .bzr.bat .bzr.bat
if not exist .bzr cd ..
if exist .bzr.bat .bzr.bat
if not exist .bzr cd ..
if exist .bzr.bat .bzr.bat
if not exist .bzr cd ..
if exist .bzr.bat .bzr.bat
echo Bazaar-Explorer: %CD%
bzrw.exe explorer .
bzr.exe version-info >_bzr_version.txt
goto :ende

:ende
exit /B

Dieses File kann entweder parameterlos gerufen werden oder mit den Parametern

bzre.bat cd aktuelles_Verzeichnis

Anhängig davon ob im angegebenen aktuellen Verzeichnis oder mehreren übergeordneten Verzeichnissen entweder ein Verzeichnis <code>.bzr</code> vorgefunden wird - das wäre also ein lokales eigenes Archiv - oder es wird ein File <code>.bzr.bat</code> vorgefunden, wird entweder der Bazaar-Explorer mit dem vorhandenen lokalen Archiv gerufen, oder es wird das oben aufgeführte <code>bzr_mvExpl.bat</code> aufgerufen, das das Archiv hin-und herkopiert. Man hat also einen Aufruf für alle vorkommenden Fälle und kann den Bazaar-Explorer unabhängig und schnell starten, ohne nachdenken und suchen zu müssen.

====Synchronisierung mehrerer Bearbeiter====

Wenn jeder sein eigenes bzr-Archiv hat und es wird gemerged, dann ist das so wie es Bazaar vorsieht.

Wenn es aber einen Hauptbearbeiter gibt und mehrere eher Nutzer dieser Sources, dann kann es auch eine File-diff-Tool-Abstimmung geben wie oben dargestellt. Man muss sich nur ab und zu in einem Netzwerk treffen. Es will nicht jeder immer und überall alle Files ändern.

==Source Content Management oder hart archivieren? Nur Quellen im SCM?==

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.

===Quellen und Generate in einem Verzeichnis ?===

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.

===Archivierung der Datenbasis des SCM===

Die Datenbasis besteht aus Files, die in üblicher Art als File-Bündel archiviert und restauriert werden können.

==Mehrere Produkte aus einem Repository==
@ident=SCM-Cmpn-de

Das große Thema ist Wiederverwendung (Reuse). Häufig zu Beobachten: Reuse besteht aus copy'n paste and change. Die Quellen wandern also irgendwo anders hin, bzgl SCM auch für den einzelnen besser zu beherrschen - man muss sich nur mit dem beschäftigen, was man selbst hat.

Das ist keine wirkliche Wiederverwendung. Der wirkliche Vorteil des reuse geht dabei verloren:
* Fehler, die in Produkten festgestellt werden, werden in den jeweiligen Modulen korrigiert und sind dann automatisch auch für andere Produkte mit korrigiert, obwohl sie dort ggf. noch gar nicht aufgefallen sind.

Für true-reuse ist es notwendig, die Software-Module so zu bauen, dass sie '''unverändert''' in verschiedenen Produkten verwendbar sind und das Änderungen für alle Produkte nutzbar sind. Das ist eine Frage der Schnittstellen. Die Schnittstellen sind viel wichtiger als die innere Funktionalität. Letztere kann man immer noch verbessern. Schnittstellenänderungen sind kritisch. - Andererseits sind Schnittstellenänderungen auch verträglich, wenn sie formell adaptiert werden können.

Ein shared-Repository in bazaar scheint die Lösung zu bieten, aus einem recht großen Quellenumfang für verschiedene Komponenten verschiedene Quellen herauslösen zu können. Die Komponenten haben selbe gemeinsame Quellen, ggf. in verschiedenen Revisionen, die aber immer abgeglichen werden können sollten. Die Komponenten sind dann Basis für ein Produkt. Komponenten existieren in Form von libs oder jars in Java und können eigenständig getestet werden:

Quellen Komponenten Produkte
viele ===> weniger Details ===> aus Komponenten
verschiedene überschaubarer und Produkt-spezial-Quellen
gebaut.

Wie funktioniert shared-Repository als zentraler Bezug - bin beim testen. (Hartmut)

==Zentrale Ablage für Repositories==
@ident=SCM-centralRepos-de

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.

===Creating one shared repository in the local space===
The ''local space'' means any external hard disk, network folder or such which is owned by one person, by me. It is my local space, which can be used from some more people in my direct environment.

For any component of sources one shared repository should be created one time. On one sub directory per component: ''bzre: Bazaar -> Start -> Initialize: (x) Shared repository''. An existing plain branch can be pushed to them.

===Creating a branch for working===

* Create a new plain branch at the working position: ''bzre: Bazaar -> Start -> Initialize: (x) Plain branch''.
* Pull from a shared repositiory: ''Button Pull, select the shared repository, select a branch.
** If there are some files already, create the branch at a new position and then move .bzr subdir.

==Branches und dessen Auflösung==
@ident=SCM-sidebranch-en

;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.

Multi-Bazaar-Components

JcHartmut — Sun, 18 Nov 2012 19:46:41 GMT

JcHartmut: Created page with '==Software assembled with components with more as one bazaar repository=='

==Software assembled with components with more as one bazaar repository==

Source-Version-Management-en

JcHartmut — Tue, 13 Nov 2012 21:20:43 GMT

JcHartmut: bzrGetVersion.bat new

==Source code management (SCM)==
@ident=SCM-en

Links:
* [[Bazaar-guide]]: a guide to use Bazaar.

This size is the english version

==More as one Repository for one product==
@ident=SCM-Cmpn-en

;Products with more as one components.

:Products are build with more as one components. Any component should be independent from the concretely product, tested as 'component' and may be used in more as one product.

:Conclusion: Do not mix sources, separate it. Therefore any component needs its own bzr archive.

;Sources of components should be located in a subdirectory of the product source tree. It is helpfull to use sub-directories to keep tidiness.

:In linux the sub directory may be a symbolic link. It means, the sources are located anywhere other in the file tree really and they can be maintained outside of the products source tree. In windows a real copy is necessary. But note, that a tool can often gotten the sources from any pathes in the file tree. It is a problem of absolute pathes versus a local sandbox.

:Conclusion: The .bzr repositiory of a component should be located in a sub directory of the product source tree.

:The name of the sub directory should, but doesn't need be identical with the name of the component.

;Getting of source tree of a component, getting its bzr archive

To get the bzr repository for a component of a product, use a simple batch or script file inside the product file tree in that directory, where the components root directory should be stored.

srcJava_Zbnf/ ..... This is the components directory, where its srcJava_Zbnf/.bzr should be located.
getBzr-srcJava_Zbnf.bat ..... This is the batch file to get the bzr archive of the component.

The batch file contains the simple line:

bzrGetVersion srcJava_Zbnf 59

This line should be kept simple and independent of any operation system. Note, that the batchfile works under linux too, if it is set 'executable'. The batchfile calls another script, 'bzrGetVersion' and names the storing directory and the requested version.

The '''bzrGetVersion''' scriptfile should be located anywhere in the PATH of the computer. It is a thing of installation, not a thing of the designated sources of the concrete product. It contains - for windows - and should be adapted to the concretely conditions at the PC-installation:

@echo off
if not "%1"=="" goto start
:help
echo How to get a component's sources:
echo The sources are contained in an bzr archive.
echo The bzr archive may be an distributed repository.
echo An archive can exist as a copy on several places,
echo for example at an external hard disk or in network or as a local copy in another drive.
echo This batchfile either exports the files from the bzr archiv or it creates a child archiv.
echo If a child archiv was created, changes on files can be committed and merged.
echo
echo The batchfile have to be started on the destination location.
echo invkoke: bzrGetVersion NAME [REV] [CHECKOUT]
echo
echo NAME of the archiv in the central location and name of the subdir on current dir
echo REV the revision
echo CHECKOUT if set then an child archiv will be created, if missing then a file export will be done.
pause
goto :ende
:start
set NAME=%1
if not "%2" == "" set REV=-r %2
set CHECKOUT=%3
::
rem This is the path to all archives for this computer, correct it if necessary:
if "%BZR_ARCHIVEPATH%" == "" set BZR_ARCHIVEPATH=D:/Bzr
::
echo The batch renames the current directory if it is existing yet:
if not exist %NAME% goto :noCurrent
if exist %NAME%.old rmdir /S/Q %NAME%.old
if exist %NAME%.old goto :nodelOld
ren %NAME% %NAME%.old
if exist %NAME% goto :noRename
:noCurrent
::
echo copy the bzr archive and resynchronize all members with the required revision
if "%CHECKOUT%"=="" goto :export
echo on
call bzr checkout %BZR_ARCHIVEPATH%/%NAME% %NAME% %REV%
@echo on
call bzr log -n5 %REV% >%NAME%\_bzr_lastversions.txt
@echo off
goto :okresync
:export
set DIR=%CD%
cd d:\Bzr\%NAME%
echo on
call bzr export %DIR%\%NAME% %REV% --per-file-timestamps
@echo on
call bzr log -n5 %REV% >%DIR%\%NAME%\_bzr_lastversions.txt
@echo off
::pause
cd %DIR%
:okresync
if not exist %NAME% goto :noBzr
goto :ende
::
:noRename
echo can't rename %NAME% to %NAME%.old. It may be used yet. Do it manually!
pause
goto :ende
::
:nodelOld
echo can't delete %NAME%.old. It may be used yet. Do it manually!
pause
goto :ende
::
:noBzr
echo The bzr archive is not pulled. The version may be faulty or the source path of bzr does not exist.
echo See error messages above.
pause
:ende
exit /B

If you follow the command statements, you can see that an existing directory is kept, of found, but the directory of the component is get newly anytime. It assumes that all bzr archives are located in one directory in the file tree, which can be an external disk too or an network path. See 'BZR_ARCHIVEPATH'.

The content of the archive will be cloned with the 'bzr checkout' command. The files are resynchronzed therefore. An independent working with the files and the cloned archive is possible, if necessary. The working can be pushed to its parent later using 'bzr push', 'bzr merge' etc. But in most cases only the resynchronized version of files are need.

==Zentrale Ablage für Repositories==
@ident=SCM-centralRepos-de

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.

===Creating one shared repository in the local space===
The ''local space'' means any external hard disk, network folder or such which is owned by one person, by me. It is my local space, which can be used from some more people in my direct environment.

For any component of sources one shared repository should be created one time. On one sub directory per component: ''bzre: Bazaar -> Start -> Initialize: (x) Shared repository''. An existing plain branch can be pushed to them.

===Creating a branch for working===

* Create a new plain branch at the working position: ''bzre: Bazaar -> Start -> Initialize: (x) Plain branch''.
* Pull from a shared repositiory: ''Button Pull, select the shared repository, select a branch.
** If there are some files already, create the branch at a new position and then move .bzr subdir.

==Branches und dessen Auflösung==
@ident=SCM-sidebranch-en

;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.

===Side branches===
less experience

bzr checkout ../masterlocation . -r REVNR

Gets a part of trunk untio REVNR. It is similar

bzr revert -r REVNR

What is the difference???

bzr update ../masterlocation .

This copies all files in the current dir. It seems to destroy the older-revision side branch (?)

Is there a possibility to checkin changes based on a older revision, without any merge. Only the changed files based on the older revision should be stored in the bazaar repositiory - to compare with other versions or look for changes later. Background: Changing of some source files to bugfix an older software. The reason is not develop and merge.

The workflow of develop and bugfix in a decentralized team is explained in
* [[http://doc.bazaar.canonical.com/latest/en/user-guide/organizing_branches.html doc.bazaar.canonical.com/latest/en/user-guide/organizing_branches]].

But this is not the problem of side branches, more the problem of development in team.

'''An side glance to git''':

$ git branch bugfix

creates a branch named 'bugfix' in the same only one repository. It is a branch with the same revision as the current one.

$ git checkout bugfix
now switches to the named branch.

$ git reset -q COMMITNR

This moves the current revision of the current branch (it is 'bugfix' to a older revision. COMMITNR is the hash number of any commit, see git log

$ git checkout .

resynchronized all files of the selected revision.

...changing any files and

$ git commit

builds a side branch in the repository (archive).

Now a switch to another branch and its revision is possible in the same sandbox to work with it:

$ git checkout master

now switches back to this named branch and resynchronizes all files. Work with it, commit etc.

If there should be worked only at one side branch to any time, and be worked at another side branch to another time, then only one sandbox is necessary. You can switch between the branches. The files are changed, all files are stored in the git archive.

If there should be worked with more as one side branches to the same time, a copy of the git archive is necessary. The archive and the files should be stored at different places on the hard disk, or at more as one computer etc. It isn't recommended to use the same git archive, may be with an symbolic link in linux. The disadvantage is: The git archive knows the current branch, which was selected with 'checkout'. If you want to use only one archive but more as one sandbox for the files, you can have a symbolic link in the sandboxes to the same archive. But then you have to switch between the side-branches before any status, commit etc. action are done in one of the sandboxes. But be attentive to your files. You may overwrite they if you are careless. You can't do that at the same time, maybe more as one people in network. It will be confused if they are work concurrently.

I haven't test yet, but it shouldn't a problem to merge the more as one git archives without conflicts, if only one archive has changed only one side branch.

[[http://www.vishia.org/SwEng/pictures/git-side-branch-example.jpg Image: example side branches in git]]

'''Now back to bazaar''':

John A Meinel proposed the following answer:

If you want to commit new changes based on an older revision, you generally want to start a new branch. So something like

bzr branch master feature -r OLD
cd feature
bzr commit

If you are using a checkout you can do

cd checkout
bzr branch --switch -r OLD ../master ../feature

TODO test

====Experience with large project====

* Created a side branch in another directory with
bzr branch VersionNr.

* Work, work, work, supply to customer.

* Now I want to merge most of changes on the old side branch to the actual version.

* Using Bzr-Explorer. Inside the trunk (the original tree from which the side branch was taken) press the ''merge'' button,
give the path to the side branch directory where .bzr is found. It is equal to the command:

bzr merge pathToSideBranch

* Now it shows 14 Conflicts,
* The files which are not changed from base revision to actual, but changed in side, are taken from side without further enquiry.
* The files which are changed from base to actual, and also changed in side, are stored with extension
** .BASE the common base version
** .OTHER the side branch which is merged into
** .THIS the actual version in this sandbox.
* The current file without extensions is pre-merged. If changes are detect between BASE and OTHER wich are not changed between BASE and THIS,
or if changes are detect between BASE and THIS which are not changed between BASE and OTHER, both are present in the pre-merged current file.
It is able to presume that both changes are relevant.
* But if the changes at the equal position are conflictin between BASE and THIS and BASE and OTHER, then a labeling is done in the form:

>>>>>>TREE
the = code + in + this;
======
the = code + in + other;
<<<<<<MERGE
* This parts of changes should be visualized and adjusted manually.
* It may be recommended to compare all changes accurately. Use a diff tool and compare the actual file with file.THIS, file.OTHER.
For this action I use The.file.Commander with a pre-written command to call

==diff THIS==
&dj.bat <*absFile1> <*absFile1>.THIS

==diff OTHER==
&dj.bat <*absFile1> <*absFile1>.OTHER

==diff BASE==
&dj.bat <*absFile1> <*absFile1>.BASE

==diff OTH_BASE==
&dj.bat <*absFile1>.OTHER <*absFile1>.BASE

==diff THIS_BASE==
&dj.bat <*absFile1>.THIS <*absFile1>.BASE

*+ where ''dj.bat'' is a command file to call a diff-view tool.

* declaring the conflicts are resolved with command (in bzr-explorer)

bzr resolve --all

* Press refresh firt in GUI, because it is a manual command, then the conflicts are not shown any more.

* now commit all changes.

Source-Version-Management-de

JcHartmut — Sat, 10 Nov 2012 11:09:44 GMT

JcHartmut: link zu canonical

==Navigation==
* up: [[Main_Page]]
* down: TODO some examples and pattern

==Source code management (SCM)==
@ident=SCM

Links local:
* [[Bazaar-guide|Bazaar-guide]]: a guide to use Bazaar.

Links in www:
* [[http://wiki.bazaar.canonical.com/Scenarios|wiki.bazaar.canonical.com/Scenarios]]: wiki.bazaar.canonical.com/Scenarios

This size is in german, because it is discussed in a german team. It will be presented in english in the future. TODO

==Kurzer Abriss, Arbeit mit MKSSI, git, mercurial, Bazaar==
@ident=SCM-gitCo

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 [[https://bitbucket.org/jchartmut/cruntimejavalike 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.

==Einzelne Files vs. SCM-Archiv==
@ident=SCM-Files
.
===Primat der Datenhaltung im SCM===

Ein Source Content Management (SCM) wie Bazaar, git oder andere enthält alle relevanten Files einschließlich deren Versionierung in einer eigenen internen Form (Datenbasis) gespeichert. Dem gegenüber steht der ''Working tree''. Das sind die Files mit denen man arbeitet. Der ''working tree'' lässt sich jederzeit aus dem SCM für beliebige Versionen rekonstruieren. Committet man immer auch Änderungen, dann ist der ''working tree'' temporär. Man braucht ihn nur während des Editierens, Compilierens, Makens. Danach kann er ersatzlos gelöscht werden, da alles im Archiv des SCM steht.

Damit steht das SCM im Mittelpunkt. Das ist auch in Ordnung so, da dies die entscheidende Stelle für die Versionierung der Sources ist. Diesbezüglich unterscheiden sich zentrale SCM nicht von den verteilten. Lediglich - bei einem zentralem SCM braucht man die Serveranbindung.

Die Files stehen meist als ''working tree'' solange bereit, bis man sie nach vorigem ''commit'' oder ''checkin'' löscht. Damit kann man auch bei einem zentralem SCM dezentral an den Files arbeiten, wenn auch nicht einchecken oder ältere Versionen sichten.

Die Alternative, ein File-Baum nur in direkter Verbindung mit dem SCM bereitzustellen gibt es auch. Dann sind die Files nur aufrufbar, wenn das SCM läuft. Die Files werden vom Betriebssystem dann nicht auf der Festplatte mit dem üblichen Filesystem gespeichert sondern alle Filezugriffe des Betriebssystems laufen über den SCM-Treiber. Damit sind keine Files vorhanden wenn das SCM mit seinem Archiv nicht zugänglich ist. Diese Variante ist die konsequenteste Anbindung an ein SCM, aber für eine offline-Arbeit eher schwierig und daher weniger verbreitet.

Es gibt also ein '''Primat des SCM gegenüber den Einzelfiles''', das mehr oder weniger stark ist.

===Gegenentwurf - Primat der Einzelfiles, lediglich Ablage und Austausch über das SCM===

Es ist möglich, die Hauptsicht auf die Files zu legen und das SCM nur als ''Ablage'' oder Austauschmedium zu nutzen. Die Files werden dann immer beibehalten, in das SCM wird nur eingecheckt oder committet. Das SCM hat dann den Zweck, auf Altversionen rückgreifen zu können und Versionen einfach zu vergleichen. Austauschen wird man gegebenenfalls über das SCM nur bestimmte Schnittstellenfiles, wenn die Bearbeitung sonst in einer Hand liegt.

Diese Arbeitsweise hat einen entscheidenden Nachteil: Es wird gegebenenfalls nicht bemerkt, dass wichtige Files überhaupt nicht in das SCM aufgenommen worden sind. Wenn dann keine weitere Datensicherung besteht und nur noch der Datengehalt des SCM verfügbar ist, sei es wegen einem Hardwarecrash, sei es bei Bearbeiterwechsel usw, dann kommt das Böse Erwachen. Es compiliert nicht, was fehlt...

Der andere Nachteil ist, das sich möglicherweise Alt-Files ansammeln, man löscht diese nicht aus Befürchtung, irgendwo könnten diese noch wichtig sein.

Tendiert ein Bearbeiter zu der Arbeitsweise, eher Files zu behalten und nur einzuchecken, dann muss es einen Test an anderer Stelle auf Vollständigkeit der Daten im SCM geben. Am einfachsten ist dies getan, wenn auf einem leerem PC oder Verzeichnisbaum aus dem SCM ausgecheckt wird und dort alle relevanten Makeprozesse durchlaufen werden. Laufen diese fehlerfrei und ist das Ergebnis korrekt, dann sind die Sources vollständig.

===Kompromiss - Arbeit mit Files und dem SCM===

Eine kleine Anekdote:

Seit mehr als einem Jahrzehnt läuft Software auf Anlagen. Sorry, die Welt ist nicht so schnellebig wie junge Leute heute glauben. Die Software wurde zu einer Zeit erstellt (seit 1994), zu der SCM noch nicht so gängige Praxis war. Jedoch wurde die Software in fleißiger Arbeit postum eingecheckt, prozess-konform, wie es sich ordentlich gehört. - Ein paar Jahre später, Nachbesserung von Hardware auf der Anlage, gegebenenfalls ist die Software betroffen. Mittlerweile war das SCM die "alte Version", doch selbstverständlich, man hat ja Zugänge und Archive gespeichert. 1 Tag Arbeit, und der Zugang funktioniert. Nun jedoch zeigte es sich, das zwar damals alles ordentlich eingecheckt wurde, aber nur die offensichtlichen Endstände. Da fehlte etwas, da stimmt was nicht - da war doch noch was ????. Bis ein Kollege damit herausrückte, er hat mal alle Stände auf CD direkt archiviert, die CD liegt im Schrank.

Die Files auf der CD hatten dann tatsächlich für mich als Entwickler einen hohen Wiedererkennungswert, wichtig dabei die Verzeichnisstruktur. Da die Backups von den laufenden Arbeitsstadionen gezogen worden sind, direkt ohne Zusatzaufwand als Filebaum, war eine Vollständigkeit gewährleistet. Die Zusatzarbeit des Eincheckens in das damalige SCM versionsgetreu hatte also Informationen verwässert.

Mit Diff-View auf den Files war dann schnell wieder der Überblick über den Gang der Entwicklung da. Übrigens - wenn man alles sehr fein säuberlich dokumentiert, auf 100 Seiten oder mehr, muss man dann später die 134 Seiten wieder lesen - ist auch Aufwand.

==>Über lange Jahre ist zwar ein SCM-System stabil und kritikunwürdig (ja klar), aber die Arbeit damit nicht. Zum Glück hat man dann backups der Files direkt.

==>Ein SCM ist wichtig für die zeitnahe Arbeit. Insbesondere für das Diff-View und die Nachverfolgung, wann wurde was geändert. Ohne SCM ist nicht!!! Aber die Arbeit direkt mit den Files hat auch seine Vorteile.

==Mehrere Arbeitsverzeichnisse, mehrere SCM-Archive, Wiederverwendung==

Wird Software stark wiederverwendet, dann erscheinen die gleichen Quellfiles möglicherweise innerhalb der jeweiligen Applikationen selbst beim selben Bearbeiter mehrfach.

Diese konsequente Art der Wiederverwendung ist nicht häufig anzutreffen. Wiederverwendung wird meist verstanden als ''kopiere es und pass es an''. Die konsequente Wiederverwendung - gleiche Quellen ohne Anpassung - hat den Vorteil dass Fehler oder Verbesserungen in einer Anwendung gefunden sofort auch in den anderen Anwendungen nützen. Allerdings muss man bei diesen wiederverwendeten Quellen die Unabhängigkeit von der jeweiligen Applikation beachten. Eigentlich eine konsequente Softwaretechnologie.

Werden die Quellen mehrfach für verschiedene Applikationen benutzt, dann kann nicht vorausgesetzt werden, dass alle Projekte mit einem einheitlichen Stand der Quellen arbeiten. Wünschenswert ist es zwar, dass an allen Stellen mit der selben Version gearbeitet wird, eben wegen der Vorteile. Andererseits kann aber eine Änderung in einer Applikation zwar allgemeingültig erfolgen, jedoch nicht fehlerfrei und allgemeingültig genug. In einer anderen Applikation können sich Folgefehler ergeben, die erst gefunden und getestet werden müssen. Ergebnis dessen ist zwar eine verbesserte Allgemeingültigkeit, jedoch ist dies mit Arbeit verbunden. Für Bugfixes aus Sicht einer Anwendung werden sich daher Differenzen nicht vermeiden lassen.

Damit sind möglicherweise Seitenzweige im Archiv des SCM erforderlich. Andererseits sollte ein Zuviel an Seitenzweigen vermieden werden, besser ist es jeweils nach Korrekturen den Hauptzweig anzuwenden. Die Seitenzweige sollten eher temporärer Natur sein.

Das SCM Bazaar unterstützt Seitenzweige mit automatisch unterstütztem merge.

===Vermeiden von Seitenzweigen bei Änderungen gemeinsamer Quellen für verschiedene Anwendungen zeitlich nacheinander===

Um Seitenzweige zu vermeiden, kann sich folgende Vorgehensweise als geeignet erweisen:

* Angenommen, eine Applikation A verwendet die Hauptversion 123.

* In einer anderen Applikation B werden in einer gemeinsamen Source-Komponente Verbesserungen vorgenommen. Damit entsteht letzlich die Hauptverson 137.

* Nun wird versucht, die Hauptversion 137 auch in A anzuwenden. Angenommen, es gibt Anpassungsnotwendigkeiten, die sich erst aus Sicht der Applikation A zeigen aber insgesamt die gemeinsame Komponente aufwerten. Es entsteht Hauptversion 139.

* Nun sollte diese Hauptversion auch für B anwendbar sein. Hat man Schnittstellen gut definiert, dann sollte es nicht unbedingt schon wieder Komplikationen geben. Es bleibt also bei der 139.

* Das Ganze soll nun auch für weitere Applikationen passen. Eventuell sind wiederum Anpassarbeiten notwendig.

Werden die Anpassungen nicht nacheinander sondern parallel ausgeführt, von verschiedenen Bearbeitern, dann entstehen zwischendurch Seitenzweige, die jeweils wieder bereinigt werden müssen. Diese Bereinigungen sind teils mergen, teils Schnittstellen klarer formulieren, teils Verbesserungen für allgemeingültige Verwendung. Es ist nun günstig, diese Bereinigungen in einer Referenzapplikation zentralisiert auszuführen. Der Test, ob die Ergebnisse bei den einzelnen Applikationen passt, ist dann wieder dezentralisiert.

Verwendet man Bazaar, dann entstehen dezentralisiert divergierende Versionen. Diese in einem Baum zusammenzufassen kann sich gegebenenfalls als nicht zweckmäßig erweisen. Gegebenenfalls ist es besser, in der zentralisierten Bearbeitung der Komponente mit der Referenzapplikation zwar alle Inputs zu verwerten, aber nicht auch alle nuancierte Änderungen im Original zu berücksichtigen. Oft ist ein Austausch - eine kompatible aber bessere Variante - die einfache Lösung, die auch Zufriedenheit bei den einzelnen Applikationen auslöst.

Damit ergibt sich allerdings die Situation, dass das formelle Arbeiten mit den Bazaar-Archiven nicht funktioniert. Denn:

* Applikation A hat ihre Version 125 abgegeben (merge-Input), die eine Verbesserung der zuvor erhaltenen (poll) Version 123 darstellt.

* Applikation B hat aber in ihrer Version 137 aus der gemeinsamen Versionen 123 hervorgegangen möglicherweise adäquate aber nicht gleiche Lösungen gefunden, die auch der Verbesserung in A entsprechen.

* Die zentralisierte Bereinigung entschließt sich daher, zwar die Funktionalität von A in 125 in der Nachbearbeitung zu garantieren, enthält aber nicht formell den Versionsstand 125 von A. Die nachbearbeitete Komponente wird also als Version 137 wieder der Applikation A angeboten, jedoch nicht passend in Archivbaum, der in A verwendet wird.

* A muss nun einerseits möglichst positiv entscheiden, dass die Änderungen zu Version 137 überhaupt benutzt werden. Die positive Entscheidung bedeutet die Fortsetzung der Partizipation an der Weiterentwicklung in der Zukunft. Andererseits muss A den Aufwand treiben, zu testen, dass es keine negativen Auswirkungen gibt.

* Formell kann die Applikation A nicht das bisherige SCM-Archiv einfach updaten, da die eigene letzte Version nicht enthalten ist.

* Zielführender ist es, nun auf der Basis der Sichtung der Differenzen der Files zu entscheiden, welche Tests ausgeführt werden müssen und welche Auswirkungen zu erwarten sind. Möglicherweise findet sich die Funktionalität der ursprünglichen Verbesserung 125 in A in nur in wenigen Zeilen nicht identisch aber passend ausgeführt. Alle anderen Änderungen sind nicht relevant da sie nicht verwendete Funktionen betreffen. Es ist also auf Basis der File-Differenz-Sichtung leicht zu entscheiden, dass nunmehr auf der neuen Version 137 aufgesetzt wird.

* Das SCM-Archiv kann nun in der Applikation A neu importiert werden, das alte Archiv wird gelöscht. Es enthielt zwar die Änderungen von 123 auf 125, die sich im neuen Archiv nicht finden, angenommenerweise ist diese Version 125 in A aber nicht pflegerelevant.

Dieses Szenario kann durchaus als typisch bezeichnet werden. Die meisten Änderungen werden kompatibel vorgenommen oder treffen nicht für alle Applikationen zu, wenn sorgsam in der Komponentenentwicklung gearbeitet wird.

Damit verschiebt sich allerdings die '''Sicht vom Primat des SCM-Archivs auf das Primat der Files'''. Zumindestens während des Überganges der Nutzung der neuen Hauptversion 137.

Wie sollte konkret umgegangen werden:

* Die neue Hauptversion 137 der Komponente wird aus dem erhaltenem SCM-Archiv auf einer unabhängigen Stelle im Filesystem als Workingtree exportiert. Die Files der Komponente in der Applikation werden nicht geändert.

* Nun erfolgt der Einzelfilevergleich zwischen dem neuen Workingtree und den bestehenden Files. Selbstverständlich sind dabei die Einträge im Log des SCM-Archives für das Verständnis der Änderungen wichtig. Letzlich werden aber die Inhalte der Files auf Passfähigkeit begutachtet.

* Im zweiten Schritt werden die neuen Files als File, nicht über das SCM-Archiv in die bisherige Applikation kopiert und die im alten aber nicht im neuen Archiv befindliche Files werden gelöscht. Letzteres ist wesentlich und typisch wenn in der Komponente umstrukturiert wurde. Das bisherige Archiv, im Beispiel auf der 125 stehend, wird erstmal weiterverwendet. Der neue Stand wird also als 126 committet.

* Danach erfolgt der Test von A.

* Im Idealfall passt alles. Es gibt keine Änderungen. Etwas weniger ideal aber erwartbar ist, dass der Stand der Komponente 137 vollständig akzeptierbar ist, allerdings sind kleine Nachbesserungen in der Applikation notwendig.

* In diesen beiden Fällen kann dann das Archiv ausgetauscht werden. Das alte SCM-Archiv mit den Versionsständen 123, 125 und zuletzt 126 wird entfernt, statt dessen das gelieferte Archiv mit der 137 eingesetzt. Im Archiv kann dann nachgelesen werden, welche Änderungen es insgesamt in der Komponente gab, auch wenn sich diese nicht aus der Applikation A ergeben hatten. Möglicherweise sind diese Änderungen für die Weiterentwicklung von A interessant oder wichtig.

Der Fall der notwendigen Nachbesserung in der Komponente, weil die Funktionalität in A nicht passt, erfordert den oben beispielhaft dargestellten Zyklus der Nachbesserung in der Komponente mit notwendigem Aufwand wiederum für alle Applikationen. Entweder dieser Aufwand ist gerechtfertigt oder möglich. Oder nach entsprechenden Klärungen ordnet sich die Applikation A dem gegebenen Stand der Komponente unter, oder mindestens vorerst wird weiter mit der eigenen Variante A gefahren.

* Konkret kann dabei auf der neu gelieferten Version 137 mit neuem Archiv aufgesetzt werden: Dort werden die notwendigen Änderungen vorgenommen und das ganze wird als neuer Versionsstand 138 aus Sicht der Applikation A an die zentrale Komponentenentwicklung zurückgeliefert.

* Der Zyklus beginnt damit erneut, hoffentlich mit kleinen und kompatibel ausführbaren Änderungen, die für eine Beruhigung der Zyklen sorgt.

===Überblick über die Anzahl Archive für die selbe Softwarekomponente ?===

Die Kapitelüberschrift ist mit einem Fragezeichen versehen.

Angenommen, es gibt etwa 10+x Stellen, an denen die selbe Softwarekomponente eingesetzt wird. Das kann sich auf mehrere PCs und Bearbeiter verteilen, auch auf dem selben PC mag es mehrere Stellen geben, weil die Softwarekomponente eben in verschiedenen Applikationen drinsteckt.

Bazaar sieht nun vor, an jedem Working tree ein eigenes Archiv zu haben. Man kann mit Bazaar-Bordmitteln dann pushen, pullen, mergen jeweils mit einem anderen Archiv. Insbesondere kann an jedem Archiv auch ein 'submit-branch'' angegeben werden (Settings - configuration - branch). Damit kann unaufwändig ein etwas zentraleres Archiv angesprochen und beobachtet werden.

Dennoch, bei 10+x Archiven, die sich gut gegeneinander updaten lassen, können sich Unterschiede breitmachen und Merge-Aufwand erzeugen, die überhaupt nicht gewünscht sind. Außerdem kann man leicht den Überblick verlieren, wo denn überhaupt welche Bearbeitung stattgefunden hat. Beim Mergen muss man dann erst einmal überlegen, was denn die bessere Version ist. Damit artet das Ganze in Arbeit aus, die man doch vermeiden und verbessern wollte ....

Außerdem kann es passieren, das in den Weiten eines Verzeichnisbaumes die Archive nicht mehr gefunden werden. Man hat also vor ein paar Monaten eine Arbeit fortgesetzt, das Archiv an eine andere Stelle kopiert, dann kamen andere Themen dazwischen. Merkt man sich immer wo man als letztes dran war oder kommt es vor, dass eine Arbeit wegen der eigenen Vergesslichkeit doppelt gemacht wird? Irren ist menschlich, aber eine gute Organisation auf dem Computer sollte Irrtümern vorbeugen.

Die Arbeit mit einem zentralen Archiv gestaltet sich dann einfacher, wenn das es eigentlich nur einen Hauptzweig gibt und Unterschiede vermieden werden sollen. Unterschiede entstehen eigentlich eher unerwünscht bei Parallelarbeiten und sind möglichst schnell wieder abzustellen.

Es soll hier aber nicht den zentralen Archiven das Wort geredet werden. Der Vorteil der dezentralen Archive ist gerade ein gewisses unabhängiges Arbeiten und eine gute Merge-Unterstützung. Jedoch - total denzentral kann auch zuviel des Guten sein.

Zweckdienlich kann es sein, für einen Bearbeiter auf einem PC nur ein Archiv zu halten. Voraussetzung dafür ist aber, das alle Applikationen tatsächlich immer mit den gleichen Source-Versionsstand compiliert werden sollen. Ich habe auf einem PC auch nur eine Entwicklungsumgebung (Eclipse für Java), in der alle Quellen für alle Projekte eingebunden sind. Damit ist es bei Strukturänderungen relativ einfach, die automatischen Möglichkeiten des Tools zu nutzen (renaming, wird automatisch in allen sichtbaren Quellen nachgezogen). Außerdem gewinnt man bei möglicherweise problematisch inkompatiblen Änderungen sofort den Überblick, wo es klemmen könnte. Es wird jeweils alles compiliert. Diese Arbeitsweise hat sich bewährt.

Dennoch, für die einzelnen Applikationen gibt es bei mir verschiedene Stellen im Filesystem (Working area). Wichtig ist, dass eine Änderung eben gerade ausgeführt mit Auswirkungen auf Applikation X zwar formell compilierfähig ist aber damit noch nicht getestet, sich nicht sofort auf einen Auslieferungsstand mit Feinkorrektur auswirkt. An diesen Stellen compiliere ich mit einem Batch-Aufruf. Das ist einfacher. Beim Batch-Aufruf werden die Files in der Working-Area benutzt. Bei einer Feinkorrektur braucht es keinen entwicklungsumgebungsunterstützten Test mit Schritt-Debugging usw. Die Korrektur wird textuell ausgeführt, compiliert und zur Laufzeit getestet.

Ein Gesamttest wird aber in dem zentralem Eclipse-Projekt mit zentralisierten Files. Damit wird immer auf dem letzten Stand basierend getestet. Von dieser zentralisierter Working-Area wird dann das Archiv (Bazaar) gepflegt, von dort wird committed.

Wie kommt aber nun eine Detailänderung aus einer denzentralen Workingarea in das Archiv? Wie kommt der letzte Archivstand in die dezentrale Working-Area?

Für die zweite Frage gäbe es eine Antwort:

bzr export %DST% --per-file-timestamps -r %REVISION%

Damit werden nur Files nach %DST% kopiert, sogar mit dem originalem Datum (geht nicht bei Unix), optional mit einer angegebenen Revisionskennzeichnung. Aber: Das ist ein blindes kopieren. Man sieht nicht vorher, welche Änderungen sich damit ergeben. Man übersieht und überschreibt für immer Änderungen in der Workingarea. "bzr export" eignet sich für die Erstellung einer neuen workingarea ohne Archivanbindung, nicht aber für's updaten.

Die ggf. bessere Variante liegt außerhalb des SCM, nämlich bei den altbewährten '''File-Baum-Diff-Tools'''. Da gibt es eine Menge, jeder hat seine gewohnten Tools, diese haben sich bewährt. Man kann die Unterschiede per File-Vergleich sichten und damit übersichtlich entscheiden, ob eine Änderung denn überhaupt wesentlich ist, was eine andere Änderung an Nebeneffekten bewirken könnte usw. usf. Ein Merge mit bazaar ist zwar auch ganz gut, aber es erzeugt zuerst Seitenversionen, bei denen man im Nachhinein (!) dann feststellt, dass das eigentlich unerwünschte oder unnötige Seitenzweigänderungen sind. Damit sind diese aber schon im Archiv manifestiert, haben Datenmüll erzeugt und müssen dann zusätzlich im Nachhinein wieder ausgebessert werden (Anschauen, löschen von *.THIS, *.BASE und *.OTher). Die Arbeit kann man sich sparen.

Die Lösung wäre also hier: Ein Archiv (pro PC) mit dem Haupt-Workingtree aus Haupt-Workingarea, '''manuelles Abstimmen von Files in den einzelnen Workingareas''' für die jeweiligen Applikationen. Man kann in diesem Zusammenhang "bzr export" nutzen um letzlich genau den Archivstand in eine Applikations-Workingarea hineinzulegen. Zuvor sollte die Workingarea gelöscht bzw. besser parallel gesichert und danach gelöscht werden. Erfolgt das löschen nicht, dann besteht die Gefahr, dass in der Applkations-Workingarea Files liegen, die wichtig für die Applikation sind, sich aber nicht im SCM-Archiv befinden. Das sollte unbedingt kontrolliert und vermieden werden. Wird zuerst per "move"- Befehl gelöscht und gesichert, danach die Files per "bzr export" neu eingespielt und danach compiliert, dann fallen diese Fehler auf. Bei Problemen kann man auf die gesichrten Files zurückgreifen. Letztlich sollte die Sicherung aber vernichtet werden, da sie sonst auch wieder nur Datenmüll ist.

Es gibt noch eine andere Möglichkeit des Bindens nur eines Archives an mehrere Working-Areas:

Unter Linux kann ein symbolischer Link <code>bzr.</code> auf das Archiv gelegt werden. Das Archiv muss dabei auf demselben Datenträger stehen, einige Funktionalitäten in Bazaar gehen sonst nicht. Aber es kann zentral irgendwo anders stehen. Mehrere symbolische Links können auf das selbe Archiv zeigen.

Nun kann man damit
* ''commit'' von verschiedenen Working-Areas ausführen und trifft jeweils das selbe Archiv. Die committeten Files erscheinen damit im Archiv, nicht jedoch automatisch in den anderen Working-Areas!
* den Filebaum betrachten und feststellen, welche Änderungen im Archiv passiert sind, die nicht aus dieser Workingarea stammmen. Man kann sich über die Bazaar-GUI die Differenzen anzeigen. Da Bazaar diese Arbeitsweise so nicht vorsieht, präsentieren sich die Änderungen spielelverkehrt. Geänderte Files mit neuem Stand im Archiv erscheinen als ''commitwürdig'' der alten Files. Neue Files im Archiv erscheinen als ''deleted files''. Um hier zu unterscheiden, was denn Änderungen in der speziellen Working Area sind, muss man schon die eigenen Files kennen. Dabei hilft ein kleines Backup des letzten Standes aus dem SCM, auf dem aufgesetzt worden ist, dabei wieder mit File-Diff-View außerhalb des SCM - nur um die eigenen Änderungen zu erkennen. Das ist damit eindeutig. File-Diff-Tools können teils auch direkt in Zip-Archiven arbeiten. Man benötigt also nur ein einfaches Zip-Backup angelegt bevor man in der speziellen Working area losarbeitet. Man kann auch postum über ein "bzr export" den Ausgangstand wieder erzeugen.
* committen einzelner Files, die nur in dieser Working Area geändert worden sind.
* Zuletzt über

bzr revert

*+den Stand aus dem SCM-Archiv in die working-Area hinein synchronisieren um wieder einen gemeinsamen Ausgangsstand zu haben.

Unter Windows geht das mit dem symbolischen Link nicht. Man kann aber stattdessen mit einem move-Befehl das Archiv von einem Platz auf einen anderen Hin- und Herschieben. Es sollte zuletzt immer auf dem zentralen Platz wieder landen, sonst weiß man nicht wo es aktuell steht. Der <code>move</code>-Befehl kopiert nicht die Archiv-Files auf der Festplatte sondern ändert tatsächlich nur einen Verzeichniseintrag. Das ist also von der Belastung der Festplatte und vom Zeitaufwand her gesehen sehr billig. Vorraussetzung: Selbe Partition der Festplatte!

Ich habe dazu folgende Befehlsfolge in einem zentralen Batch-File niederlegt:

File <code>bzr_mvExpl.bat</code>

set CMPN=%1
REM Add the Bzr directory to system-wide PATH environment variable
SET PATH=D:\Progs\Bazaar;%PATH%
attrib -h \Bzr\%CMPN%\.bzr
if not exist .bzr move \Bzr\%CMPN%\.bzr .bzr
echo Bazaar-Explorer:
bzrw.exe explorer .
bzr.exe version-info >_bzr_version.txt
if not exist \Bzr\%CMPN%\.bzr move .bzr \Bzr\%CMPN%
attrib +h \Bzr\%CMPN%\.bzr

Wichtig für das funktionieren des move-Befehls ist das Rücksetzen des Hidden-Attributes für das .bzr-Archiv.

Dieses File wird in einem File im Arbeitsverzeichnis (Working Area)

.bzr.bat

mit drei Zeilen

SET USERNAME=hartmut
SET BZREMAIL=hartmut.schorrig@vishia.de
bzr_mvExpl.bat srcJava_vishiaBase

aufgerufen. Das <code>srcJava_vishiaBase</code> ist hierbei der Name der Softwarekomponente und der Name des Verzeichnisses in dem das <code>.bzr</code>-Archiv steht. Alle <code>.bzr</code>-Archive stehen dabei zentral auf der selben Festplatte (keine Laufwerksangabe am Pfad) im Verzeichnis <code>\Bzr</code>. Da dies so zentral festgelegt ist, kann das Batchfile direkt darauf zugreifen. Im Start-Batchfile sind zusätzlich in lokal gültigen Umgebugsvariablen die Commit-Daten niedergelegt. Diese sind damit Working-Area-spezifisch.

Es gibt dann noch einen weiteren interessanten Batchfile:

File <code>bzre.bat</code>

@echo off
REM Add the Bzr directory to system-wide PATH environment variable
SET PATH=D:\Progs\Bazaar;%PATH%
SET USERNAME=hartmut
SET BZREMAIL=hartmut.schorrig@vishia.de
::
if not "%1" == "cd" goto :nocd
echo on
cd %2
echo off
:nocd
REM if the directory contains .bzr.bat, it is processed. It doesnt return!
REM if the directory or any parent does not contain .bzr change to the parent.
if exist .bzr.bat .bzr.bat
if not exist .bzr cd ..
if exist .bzr.bat .bzr.bat
if not exist .bzr cd ..
if exist .bzr.bat .bzr.bat
if not exist .bzr cd ..
if exist .bzr.bat .bzr.bat
echo Bazaar-Explorer: %CD%
bzrw.exe explorer .
bzr.exe version-info >_bzr_version.txt
goto :ende

:ende
exit /B

Dieses File kann entweder parameterlos gerufen werden oder mit den Parametern

bzre.bat cd aktuelles_Verzeichnis

Anhängig davon ob im angegebenen aktuellen Verzeichnis oder mehreren übergeordneten Verzeichnissen entweder ein Verzeichnis <code>.bzr</code> vorgefunden wird - das wäre also ein lokales eigenes Archiv - oder es wird ein File <code>.bzr.bat</code> vorgefunden, wird entweder der Bazaar-Explorer mit dem vorhandenen lokalen Archiv gerufen, oder es wird das oben aufgeführte <code>bzr_mvExpl.bat</code> aufgerufen, das das Archiv hin-und herkopiert. Man hat also einen Aufruf für alle vorkommenden Fälle und kann den Bazaar-Explorer unabhängig und schnell starten, ohne nachdenken und suchen zu müssen.

====Synchronisierung mehrerer Bearbeiter====

Wenn jeder sein eigenes bzr-Archiv hat und es wird gemerged, dann ist das so wie es Bazaar vorsieht.

Wenn es aber einen Hauptbearbeiter gibt und mehrere eher Nutzer dieser Sources, dann kann es auch eine File-diff-Tool-Abstimmung geben wie oben dargestellt. Man muss sich nur ab und zu in einem Netzwerk treffen. Es will nicht jeder immer und überall alle Files ändern.

==Source Content Management oder hart archivieren? Nur Quellen im SCM?==

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.

===Quellen und Generate in einem Verzeichnis ?===

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.

===Archivierung der Datenbasis des SCM===

Die Datenbasis besteht aus Files, die in üblicher Art als File-Bündel archiviert und restauriert werden können.

==Mehrere Produkte aus einem Repository==
@ident=SCM-Cmpn-de

Das große Thema ist Wiederverwendung (Reuse). Häufig zu Beobachten: Reuse besteht aus copy'n paste and change. Die Quellen wandern also irgendwo anders hin, bzgl SCM auch für den einzelnen besser zu beherrschen - man muss sich nur mit dem beschäftigen, was man selbst hat.

Das ist keine wirkliche Wiederverwendung. Der wirkliche Vorteil des reuse geht dabei verloren:
* Fehler, die in Produkten festgestellt werden, werden in den jeweiligen Modulen korrigiert und sind dann automatisch auch für andere Produkte mit korrigiert, obwohl sie dort ggf. noch gar nicht aufgefallen sind.

Für true-reuse ist es notwendig, die Software-Module so zu bauen, dass sie '''unverändert''' in verschiedenen Produkten verwendbar sind und das Änderungen für alle Produkte nutzbar sind. Das ist eine Frage der Schnittstellen. Die Schnittstellen sind viel wichtiger als die innere Funktionalität. Letztere kann man immer noch verbessern. Schnittstellenänderungen sind kritisch. - Andererseits sind Schnittstellenänderungen auch verträglich, wenn sie formell adaptiert werden können.

Ein shared-Repository in bazaar scheint die Lösung zu bieten, aus einem recht großen Quellenumfang für verschiedene Komponenten verschiedene Quellen herauslösen zu können. Die Komponenten haben selbe gemeinsame Quellen, ggf. in verschiedenen Revisionen, die aber immer abgeglichen werden können sollten. Die Komponenten sind dann Basis für ein Produkt. Komponenten existieren in Form von libs oder jars in Java und können eigenständig getestet werden:

Quellen Komponenten Produkte
viele ===> weniger ===> aus Komponenten
verschiedene überschaubar und Produkt-spezial-Quellen
gebaut.

Wie funktioniert shared-Repository als zentraler Bezug - bin beim testen. (Hartmut)
==Zentrale Ablage für Repositories==
@ident=SCM-centralRepos-de

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.

===Creating one shared repository in the local space===
The ''local space'' means any external hard disk, network folder or such which is owned by one person, by me. It is my local space, which can be used from some more people in my direct environment.

For any component of sources one shared repository should be created one time. On one sub directory per component: ''bzre: Bazaar -> Start -> Initialize: (x) Shared repository''. An existing plain branch can be pushed to them.

===Creating a branch for working===

* Create a new plain branch at the working position: ''bzre: Bazaar -> Start -> Initialize: (x) Plain branch''.
* Pull from a shared repositiory: ''Button Pull, select the shared repository, select a branch.
** If there are some files already, create the branch at a new position and then move .bzr subdir.

==Branches und dessen Auflösung==
@ident=SCM-sidebranch-en

;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.

Source-Version-Management-de

JcHartmut — Fri, 09 Nov 2012 23:22:38 GMT

JcHartmut: Archive nicht mehr gefunden?

==Navigation==
* up: [[Main_Page]]
* down: TODO some examples and pattern

==Source code management (SCM)==
@ident=SCM

Links:
* [[Bazaar-guide]]: a guide to use Bazaar.

This size is in german, because it is discussed in a german team. It will be presented in english in the future. TODO

==Kurzer Abriss, Arbeit mit MKSSI, git, mercurial, Bazaar==
@ident=SCM-gitCo

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 [[https://bitbucket.org/jchartmut/cruntimejavalike 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.

==Einzelne Files vs. SCM-Archiv==
@ident=SCM-Files
.
===Primat der Datenhaltung im SCM===

Ein Source Content Management (SCM) wie Bazaar, git oder andere enthält alle relevanten Files einschließlich deren Versionierung in einer eigenen internen Form (Datenbasis) gespeichert. Dem gegenüber steht der ''Working tree''. Das sind die Files mit denen man arbeitet. Der ''working tree'' lässt sich jederzeit aus dem SCM für beliebige Versionen rekonstruieren. Committet man immer auch Änderungen, dann ist der ''working tree'' temporär. Man braucht ihn nur während des Editierens, Compilierens, Makens. Danach kann er ersatzlos gelöscht werden, da alles im Archiv des SCM steht.

Damit steht das SCM im Mittelpunkt. Das ist auch in Ordnung so, da dies die entscheidende Stelle für die Versionierung der Sources ist. Diesbezüglich unterscheiden sich zentrale SCM nicht von den verteilten. Lediglich - bei einem zentralem SCM braucht man die Serveranbindung.

Die Files stehen meist als ''working tree'' solange bereit, bis man sie nach vorigem ''commit'' oder ''checkin'' löscht. Damit kann man auch bei einem zentralem SCM dezentral an den Files arbeiten, wenn auch nicht einchecken oder ältere Versionen sichten.

Die Alternative, ein File-Baum nur in direkter Verbindung mit dem SCM bereitzustellen gibt es auch. Dann sind die Files nur aufrufbar, wenn das SCM läuft. Die Files werden vom Betriebssystem dann nicht auf der Festplatte mit dem üblichen Filesystem gespeichert sondern alle Filezugriffe des Betriebssystems laufen über den SCM-Treiber. Damit sind keine Files vorhanden wenn das SCM mit seinem Archiv nicht zugänglich ist. Diese Variante ist die konsequenteste Anbindung an ein SCM, aber für eine offline-Arbeit eher schwierig und daher weniger verbreitet.

Es gibt also ein '''Primat des SCM gegenüber den Einzelfiles''', das mehr oder weniger stark ist.

===Gegenentwurf - Primat der Einzelfiles, lediglich Ablage und Austausch über das SCM===

Es ist möglich, die Hauptsicht auf die Files zu legen und das SCM nur als ''Ablage'' oder Austauschmedium zu nutzen. Die Files werden dann immer beibehalten, in das SCM wird nur eingecheckt oder committet. Das SCM hat dann den Zweck, auf Altversionen rückgreifen zu können und Versionen einfach zu vergleichen. Austauschen wird man gegebenenfalls über das SCM nur bestimmte Schnittstellenfiles, wenn die Bearbeitung sonst in einer Hand liegt.

Diese Arbeitsweise hat einen entscheidenden Nachteil: Es wird gegebenenfalls nicht bemerkt, dass wichtige Files überhaupt nicht in das SCM aufgenommen worden sind. Wenn dann keine weitere Datensicherung besteht und nur noch der Datengehalt des SCM verfügbar ist, sei es wegen einem Hardwarecrash, sei es bei Bearbeiterwechsel usw, dann kommt das Böse Erwachen. Es compiliert nicht, was fehlt...

Der andere Nachteil ist, das sich möglicherweise Alt-Files ansammeln, man löscht diese nicht aus Befürchtung, irgendwo könnten diese noch wichtig sein.

Tendiert ein Bearbeiter zu der Arbeitsweise, eher Files zu behalten und nur einzuchecken, dann muss es einen Test an anderer Stelle auf Vollständigkeit der Daten im SCM geben. Am einfachsten ist dies getan, wenn auf einem leerem PC oder Verzeichnisbaum aus dem SCM ausgecheckt wird und dort alle relevanten Makeprozesse durchlaufen werden. Laufen diese fehlerfrei und ist das Ergebnis korrekt, dann sind die Sources vollständig.

===Kompromiss - Arbeit mit Files und dem SCM===

Eine kleine Anekdote:

Seit mehr als einem Jahrzehnt läuft Software auf Anlagen. Sorry, die Welt ist nicht so schnellebig wie junge Leute heute glauben. Die Software wurde zu einer Zeit erstellt (seit 1994), zu der SCM noch nicht so gängige Praxis war. Jedoch wurde die Software in fleißiger Arbeit postum eingecheckt, prozess-konform, wie es sich ordentlich gehört. - Ein paar Jahre später, Nachbesserung von Hardware auf der Anlage, gegebenenfalls ist die Software betroffen. Mittlerweile war das SCM die "alte Version", doch selbstverständlich, man hat ja Zugänge und Archive gespeichert. 1 Tag Arbeit, und der Zugang funktioniert. Nun jedoch zeigte es sich, das zwar damals alles ordentlich eingecheckt wurde, aber nur die offensichtlichen Endstände. Da fehlte etwas, da stimmt was nicht - da war doch noch was ????. Bis ein Kollege damit herausrückte, er hat mal alle Stände auf CD direkt archiviert, die CD liegt im Schrank.

Die Files auf der CD hatten dann tatsächlich für mich als Entwickler einen hohen Wiedererkennungswert, wichtig dabei die Verzeichnisstruktur. Da die Backups von den laufenden Arbeitsstadionen gezogen worden sind, direkt ohne Zusatzaufwand als Filebaum, war eine Vollständigkeit gewährleistet. Die Zusatzarbeit des Eincheckens in das damalige SCM versionsgetreu hatte also Informationen verwässert.

Mit Diff-View auf den Files war dann schnell wieder der Überblick über den Gang der Entwicklung da. Übrigens - wenn man alles sehr fein säuberlich dokumentiert, auf 100 Seiten oder mehr, muss man dann später die 134 Seiten wieder lesen - ist auch Aufwand.

==>Über lange Jahre ist zwar ein SCM-System stabil und kritikunwürdig (ja klar), aber die Arbeit damit nicht. Zum Glück hat man dann backups der Files direkt.

==>Ein SCM ist wichtig für die zeitnahe Arbeit. Insbesondere für das Diff-View und die Nachverfolgung, wann wurde was geändert. Ohne SCM ist nicht!!! Aber die Arbeit direkt mit den Files hat auch seine Vorteile.

==Mehrere Arbeitsverzeichnisse, mehrere SCM-Archive, Wiederverwendung==

Wird Software stark wiederverwendet, dann erscheinen die gleichen Quellfiles möglicherweise innerhalb der jeweiligen Applikationen selbst beim selben Bearbeiter mehrfach.

Diese konsequente Art der Wiederverwendung ist nicht häufig anzutreffen. Wiederverwendung wird meist verstanden als ''kopiere es und pass es an''. Die konsequente Wiederverwendung - gleiche Quellen ohne Anpassung - hat den Vorteil dass Fehler oder Verbesserungen in einer Anwendung gefunden sofort auch in den anderen Anwendungen nützen. Allerdings muss man bei diesen wiederverwendeten Quellen die Unabhängigkeit von der jeweiligen Applikation beachten. Eigentlich eine konsequente Softwaretechnologie.

Werden die Quellen mehrfach für verschiedene Applikationen benutzt, dann kann nicht vorausgesetzt werden, dass alle Projekte mit einem einheitlichen Stand der Quellen arbeiten. Wünschenswert ist es zwar, dass an allen Stellen mit der selben Version gearbeitet wird, eben wegen der Vorteile. Andererseits kann aber eine Änderung in einer Applikation zwar allgemeingültig erfolgen, jedoch nicht fehlerfrei und allgemeingültig genug. In einer anderen Applikation können sich Folgefehler ergeben, die erst gefunden und getestet werden müssen. Ergebnis dessen ist zwar eine verbesserte Allgemeingültigkeit, jedoch ist dies mit Arbeit verbunden. Für Bugfixes aus Sicht einer Anwendung werden sich daher Differenzen nicht vermeiden lassen.

Damit sind möglicherweise Seitenzweige im Archiv des SCM erforderlich. Andererseits sollte ein Zuviel an Seitenzweigen vermieden werden, besser ist es jeweils nach Korrekturen den Hauptzweig anzuwenden. Die Seitenzweige sollten eher temporärer Natur sein.

Das SCM Bazaar unterstützt Seitenzweige mit automatisch unterstütztem merge.

===Vermeiden von Seitenzweigen bei Änderungen gemeinsamer Quellen für verschiedene Anwendungen zeitlich nacheinander===

Um Seitenzweige zu vermeiden, kann sich folgende Vorgehensweise als geeignet erweisen:

* Angenommen, eine Applikation A verwendet die Hauptversion 123.

* In einer anderen Applikation B werden in einer gemeinsamen Source-Komponente Verbesserungen vorgenommen. Damit entsteht letzlich die Hauptverson 137.

* Nun wird versucht, die Hauptversion 137 auch in A anzuwenden. Angenommen, es gibt Anpassungsnotwendigkeiten, die sich erst aus Sicht der Applikation A zeigen aber insgesamt die gemeinsame Komponente aufwerten. Es entsteht Hauptversion 139.

* Nun sollte diese Hauptversion auch für B anwendbar sein. Hat man Schnittstellen gut definiert, dann sollte es nicht unbedingt schon wieder Komplikationen geben. Es bleibt also bei der 139.

* Das Ganze soll nun auch für weitere Applikationen passen. Eventuell sind wiederum Anpassarbeiten notwendig.

Werden die Anpassungen nicht nacheinander sondern parallel ausgeführt, von verschiedenen Bearbeitern, dann entstehen zwischendurch Seitenzweige, die jeweils wieder bereinigt werden müssen. Diese Bereinigungen sind teils mergen, teils Schnittstellen klarer formulieren, teils Verbesserungen für allgemeingültige Verwendung. Es ist nun günstig, diese Bereinigungen in einer Referenzapplikation zentralisiert auszuführen. Der Test, ob die Ergebnisse bei den einzelnen Applikationen passt, ist dann wieder dezentralisiert.

Verwendet man Bazaar, dann entstehen dezentralisiert divergierende Versionen. Diese in einem Baum zusammenzufassen kann sich gegebenenfalls als nicht zweckmäßig erweisen. Gegebenenfalls ist es besser, in der zentralisierten Bearbeitung der Komponente mit der Referenzapplikation zwar alle Inputs zu verwerten, aber nicht auch alle nuancierte Änderungen im Original zu berücksichtigen. Oft ist ein Austausch - eine kompatible aber bessere Variante - die einfache Lösung, die auch Zufriedenheit bei den einzelnen Applikationen auslöst.

Damit ergibt sich allerdings die Situation, dass das formelle Arbeiten mit den Bazaar-Archiven nicht funktioniert. Denn:

* Applikation A hat ihre Version 125 abgegeben (merge-Input), die eine Verbesserung der zuvor erhaltenen (poll) Version 123 darstellt.

* Applikation B hat aber in ihrer Version 137 aus der gemeinsamen Versionen 123 hervorgegangen möglicherweise adäquate aber nicht gleiche Lösungen gefunden, die auch der Verbesserung in A entsprechen.

* Die zentralisierte Bereinigung entschließt sich daher, zwar die Funktionalität von A in 125 in der Nachbearbeitung zu garantieren, enthält aber nicht formell den Versionsstand 125 von A. Die nachbearbeitete Komponente wird also als Version 137 wieder der Applikation A angeboten, jedoch nicht passend in Archivbaum, der in A verwendet wird.

* A muss nun einerseits möglichst positiv entscheiden, dass die Änderungen zu Version 137 überhaupt benutzt werden. Die positive Entscheidung bedeutet die Fortsetzung der Partizipation an der Weiterentwicklung in der Zukunft. Andererseits muss A den Aufwand treiben, zu testen, dass es keine negativen Auswirkungen gibt.

* Formell kann die Applikation A nicht das bisherige SCM-Archiv einfach updaten, da die eigene letzte Version nicht enthalten ist.

* Zielführender ist es, nun auf der Basis der Sichtung der Differenzen der Files zu entscheiden, welche Tests ausgeführt werden müssen und welche Auswirkungen zu erwarten sind. Möglicherweise findet sich die Funktionalität der ursprünglichen Verbesserung 125 in A in nur in wenigen Zeilen nicht identisch aber passend ausgeführt. Alle anderen Änderungen sind nicht relevant da sie nicht verwendete Funktionen betreffen. Es ist also auf Basis der File-Differenz-Sichtung leicht zu entscheiden, dass nunmehr auf der neuen Version 137 aufgesetzt wird.

* Das SCM-Archiv kann nun in der Applikation A neu importiert werden, das alte Archiv wird gelöscht. Es enthielt zwar die Änderungen von 123 auf 125, die sich im neuen Archiv nicht finden, angenommenerweise ist diese Version 125 in A aber nicht pflegerelevant.

Dieses Szenario kann durchaus als typisch bezeichnet werden. Die meisten Änderungen werden kompatibel vorgenommen oder treffen nicht für alle Applikationen zu, wenn sorgsam in der Komponentenentwicklung gearbeitet wird.

Damit verschiebt sich allerdings die '''Sicht vom Primat des SCM-Archivs auf das Primat der Files'''. Zumindestens während des Überganges der Nutzung der neuen Hauptversion 137.

Wie sollte konkret umgegangen werden:

* Die neue Hauptversion 137 der Komponente wird aus dem erhaltenem SCM-Archiv auf einer unabhängigen Stelle im Filesystem als Workingtree exportiert. Die Files der Komponente in der Applikation werden nicht geändert.

* Nun erfolgt der Einzelfilevergleich zwischen dem neuen Workingtree und den bestehenden Files. Selbstverständlich sind dabei die Einträge im Log des SCM-Archives für das Verständnis der Änderungen wichtig. Letzlich werden aber die Inhalte der Files auf Passfähigkeit begutachtet.

* Im zweiten Schritt werden die neuen Files als File, nicht über das SCM-Archiv in die bisherige Applikation kopiert und die im alten aber nicht im neuen Archiv befindliche Files werden gelöscht. Letzteres ist wesentlich und typisch wenn in der Komponente umstrukturiert wurde. Das bisherige Archiv, im Beispiel auf der 125 stehend, wird erstmal weiterverwendet. Der neue Stand wird also als 126 committet.

* Danach erfolgt der Test von A.

* Im Idealfall passt alles. Es gibt keine Änderungen. Etwas weniger ideal aber erwartbar ist, dass der Stand der Komponente 137 vollständig akzeptierbar ist, allerdings sind kleine Nachbesserungen in der Applikation notwendig.

* In diesen beiden Fällen kann dann das Archiv ausgetauscht werden. Das alte SCM-Archiv mit den Versionsständen 123, 125 und zuletzt 126 wird entfernt, statt dessen das gelieferte Archiv mit der 137 eingesetzt. Im Archiv kann dann nachgelesen werden, welche Änderungen es insgesamt in der Komponente gab, auch wenn sich diese nicht aus der Applikation A ergeben hatten. Möglicherweise sind diese Änderungen für die Weiterentwicklung von A interessant oder wichtig.

Der Fall der notwendigen Nachbesserung in der Komponente, weil die Funktionalität in A nicht passt, erfordert den oben beispielhaft dargestellten Zyklus der Nachbesserung in der Komponente mit notwendigem Aufwand wiederum für alle Applikationen. Entweder dieser Aufwand ist gerechtfertigt oder möglich. Oder nach entsprechenden Klärungen ordnet sich die Applikation A dem gegebenen Stand der Komponente unter, oder mindestens vorerst wird weiter mit der eigenen Variante A gefahren.

* Konkret kann dabei auf der neu gelieferten Version 137 mit neuem Archiv aufgesetzt werden: Dort werden die notwendigen Änderungen vorgenommen und das ganze wird als neuer Versionsstand 138 aus Sicht der Applikation A an die zentrale Komponentenentwicklung zurückgeliefert.

* Der Zyklus beginnt damit erneut, hoffentlich mit kleinen und kompatibel ausführbaren Änderungen, die für eine Beruhigung der Zyklen sorgt.

===Überblick über die Anzahl Archive für die selbe Softwarekomponente ?===

Die Kapitelüberschrift ist mit einem Fragezeichen versehen.

Angenommen, es gibt etwa 10+x Stellen, an denen die selbe Softwarekomponente eingesetzt wird. Das kann sich auf mehrere PCs und Bearbeiter verteilen, auch auf dem selben PC mag es mehrere Stellen geben, weil die Softwarekomponente eben in verschiedenen Applikationen drinsteckt.

Bazaar sieht nun vor, an jedem Working tree ein eigenes Archiv zu haben. Man kann mit Bazaar-Bordmitteln dann pushen, pullen, mergen jeweils mit einem anderen Archiv. Insbesondere kann an jedem Archiv auch ein 'submit-branch'' angegeben werden (Settings - configuration - branch). Damit kann unaufwändig ein etwas zentraleres Archiv angesprochen und beobachtet werden.

Dennoch, bei 10+x Archiven, die sich gut gegeneinander updaten lassen, können sich Unterschiede breitmachen und Merge-Aufwand erzeugen, die überhaupt nicht gewünscht sind. Außerdem kann man leicht den Überblick verlieren, wo denn überhaupt welche Bearbeitung stattgefunden hat. Beim Mergen muss man dann erst einmal überlegen, was denn die bessere Version ist. Damit artet das Ganze in Arbeit aus, die man doch vermeiden und verbessern wollte ....

Außerdem kann es passieren, das in den Weiten eines Verzeichnisbaumes die Archive nicht mehr gefunden werden. Man hat also vor ein paar Monaten eine Arbeit fortgesetzt, das Archiv an eine andere Stelle kopiert, dann kamen andere Themen dazwischen. Merkt man sich immer wo man als letztes dran war oder kommt es vor, dass eine Arbeit wegen der eigenen Vergesslichkeit doppelt gemacht wird? Irren ist menschlich, aber eine gute Organisation auf dem Computer sollte Irrtümern vorbeugen.

Die Arbeit mit einem zentralen Archiv gestaltet sich dann einfacher, wenn das es eigentlich nur einen Hauptzweig gibt und Unterschiede vermieden werden sollen. Unterschiede entstehen eigentlich eher unerwünscht bei Parallelarbeiten und sind möglichst schnell wieder abzustellen.

Es soll hier aber nicht den zentralen Archiven das Wort geredet werden. Der Vorteil der dezentralen Archive ist gerade ein gewisses unabhängiges Arbeiten und eine gute Merge-Unterstützung. Jedoch - total denzentral kann auch zuviel des Guten sein.

Zweckdienlich kann es sein, für einen Bearbeiter auf einem PC nur ein Archiv zu halten. Voraussetzung dafür ist aber, das alle Applikationen tatsächlich immer mit den gleichen Source-Versionsstand compiliert werden sollen. Ich habe auf einem PC auch nur eine Entwicklungsumgebung (Eclipse für Java), in der alle Quellen für alle Projekte eingebunden sind. Damit ist es bei Strukturänderungen relativ einfach, die automatischen Möglichkeiten des Tools zu nutzen (renaming, wird automatisch in allen sichtbaren Quellen nachgezogen). Außerdem gewinnt man bei möglicherweise problematisch inkompatiblen Änderungen sofort den Überblick, wo es klemmen könnte. Es wird jeweils alles compiliert. Diese Arbeitsweise hat sich bewährt.

Dennoch, für die einzelnen Applikationen gibt es bei mir verschiedene Stellen im Filesystem (Working area). Wichtig ist, dass eine Änderung eben gerade ausgeführt mit Auswirkungen auf Applikation X zwar formell compilierfähig ist aber damit noch nicht getestet, sich nicht sofort auf einen Auslieferungsstand mit Feinkorrektur auswirkt. An diesen Stellen compiliere ich mit einem Batch-Aufruf. Das ist einfacher. Beim Batch-Aufruf werden die Files in der Working-Area benutzt. Bei einer Feinkorrektur braucht es keinen entwicklungsumgebungsunterstützten Test mit Schritt-Debugging usw. Die Korrektur wird textuell ausgeführt, compiliert und zur Laufzeit getestet.

Ein Gesamttest wird aber in dem zentralem Eclipse-Projekt mit zentralisierten Files. Damit wird immer auf dem letzten Stand basierend getestet. Von dieser zentralisierter Working-Area wird dann das Archiv (Bazaar) gepflegt, von dort wird committed.

Wie kommt aber nun eine Detailänderung aus einer denzentralen Workingarea in das Archiv? Wie kommt der letzte Archivstand in die dezentrale Working-Area?

Für die zweite Frage gäbe es eine Antwort:

bzr export %DST% --per-file-timestamps -r %REVISION%

Damit werden nur Files nach %DST% kopiert, sogar mit dem originalem Datum (geht nicht bei Unix), optional mit einer angegebenen Revisionskennzeichnung. Aber: Das ist ein blindes kopieren. Man sieht nicht vorher, welche Änderungen sich damit ergeben. Man übersieht und überschreibt für immer Änderungen in der Workingarea. "bzr export" eignet sich für die Erstellung einer neuen workingarea ohne Archivanbindung, nicht aber für's updaten.

Die ggf. bessere Variante liegt außerhalb des SCM, nämlich bei den altbewährten '''File-Baum-Diff-Tools'''. Da gibt es eine Menge, jeder hat seine gewohnten Tools, diese haben sich bewährt. Man kann die Unterschiede per File-Vergleich sichten und damit übersichtlich entscheiden, ob eine Änderung denn überhaupt wesentlich ist, was eine andere Änderung an Nebeneffekten bewirken könnte usw. usf. Ein Merge mit bazaar ist zwar auch ganz gut, aber es erzeugt zuerst Seitenversionen, bei denen man im Nachhinein (!) dann feststellt, dass das eigentlich unerwünschte oder unnötige Seitenzweigänderungen sind. Damit sind diese aber schon im Archiv manifestiert, haben Datenmüll erzeugt und müssen dann zusätzlich im Nachhinein wieder ausgebessert werden (Anschauen, löschen von *.THIS, *.BASE und *.OTher). Die Arbeit kann man sich sparen.

Die Lösung wäre also hier: Ein Archiv (pro PC) mit dem Haupt-Workingtree aus Haupt-Workingarea, '''manuelles Abstimmen von Files in den einzelnen Workingareas''' für die jeweiligen Applikationen. Man kann in diesem Zusammenhang "bzr export" nutzen um letzlich genau den Archivstand in eine Applikations-Workingarea hineinzulegen. Zuvor sollte die Workingarea gelöscht bzw. besser parallel gesichert und danach gelöscht werden. Erfolgt das löschen nicht, dann besteht die Gefahr, dass in der Applkations-Workingarea Files liegen, die wichtig für die Applikation sind, sich aber nicht im SCM-Archiv befinden. Das sollte unbedingt kontrolliert und vermieden werden. Wird zuerst per "move"- Befehl gelöscht und gesichert, danach die Files per "bzr export" neu eingespielt und danach compiliert, dann fallen diese Fehler auf. Bei Problemen kann man auf die gesichrten Files zurückgreifen. Letztlich sollte die Sicherung aber vernichtet werden, da sie sonst auch wieder nur Datenmüll ist.

Es gibt noch eine andere Möglichkeit des Bindens nur eines Archives an mehrere Working-Areas:

Unter Linux kann ein symbolischer Link <code>bzr.</code> auf das Archiv gelegt werden. Das Archiv muss dabei auf demselben Datenträger stehen, einige Funktionalitäten in Bazaar gehen sonst nicht. Aber es kann zentral irgendwo anders stehen. Mehrere symbolische Links können auf das selbe Archiv zeigen.

Nun kann man damit
* ''commit'' von verschiedenen Working-Areas ausführen und trifft jeweils das selbe Archiv. Die committeten Files erscheinen damit im Archiv, nicht jedoch automatisch in den anderen Working-Areas!
* den Filebaum betrachten und feststellen, welche Änderungen im Archiv passiert sind, die nicht aus dieser Workingarea stammmen. Man kann sich über die Bazaar-GUI die Differenzen anzeigen. Da Bazaar diese Arbeitsweise so nicht vorsieht, präsentieren sich die Änderungen spielelverkehrt. Geänderte Files mit neuem Stand im Archiv erscheinen als ''commitwürdig'' der alten Files. Neue Files im Archiv erscheinen als ''deleted files''. Um hier zu unterscheiden, was denn Änderungen in der speziellen Working Area sind, muss man schon die eigenen Files kennen. Dabei hilft ein kleines Backup des letzten Standes aus dem SCM, auf dem aufgesetzt worden ist, dabei wieder mit File-Diff-View außerhalb des SCM - nur um die eigenen Änderungen zu erkennen. Das ist damit eindeutig. File-Diff-Tools können teils auch direkt in Zip-Archiven arbeiten. Man benötigt also nur ein einfaches Zip-Backup angelegt bevor man in der speziellen Working area losarbeitet. Man kann auch postum über ein "bzr export" den Ausgangstand wieder erzeugen.
* committen einzelner Files, die nur in dieser Working Area geändert worden sind.
* Zuletzt über

bzr revert

*+den Stand aus dem SCM-Archiv in die working-Area hinein synchronisieren um wieder einen gemeinsamen Ausgangsstand zu haben.

Unter Windows geht das mit dem symbolischen Link nicht. Man kann aber stattdessen mit einem move-Befehl das Archiv von einem Platz auf einen anderen Hin- und Herschieben. Es sollte zuletzt immer auf dem zentralen Platz wieder landen, sonst weiß man nicht wo es aktuell steht. Der <code>move</code>-Befehl kopiert nicht die Archiv-Files auf der Festplatte sondern ändert tatsächlich nur einen Verzeichniseintrag. Das ist also von der Belastung der Festplatte und vom Zeitaufwand her gesehen sehr billig. Vorraussetzung: Selbe Partition der Festplatte!

Ich habe dazu folgende Befehlsfolge in einem zentralen Batch-File niederlegt:

File <code>bzr_mvExpl.bat</code>

set CMPN=%1
REM Add the Bzr directory to system-wide PATH environment variable
SET PATH=D:\Progs\Bazaar;%PATH%
attrib -h \Bzr\%CMPN%\.bzr
if not exist .bzr move \Bzr\%CMPN%\.bzr .bzr
echo Bazaar-Explorer:
bzrw.exe explorer .
bzr.exe version-info >_bzr_version.txt
if not exist \Bzr\%CMPN%\.bzr move .bzr \Bzr\%CMPN%
attrib +h \Bzr\%CMPN%\.bzr

Wichtig für das funktionieren des move-Befehls ist das Rücksetzen des Hidden-Attributes für das .bzr-Archiv.

Dieses File wird in einem File im Arbeitsverzeichnis (Working Area)

.bzr.bat

mit drei Zeilen

SET USERNAME=hartmut
SET BZREMAIL=hartmut.schorrig@vishia.de
bzr_mvExpl.bat srcJava_vishiaBase

aufgerufen. Das <code>srcJava_vishiaBase</code> ist hierbei der Name der Softwarekomponente und der Name des Verzeichnisses in dem das <code>.bzr</code>-Archiv steht. Alle <code>.bzr</code>-Archive stehen dabei zentral auf der selben Festplatte (keine Laufwerksangabe am Pfad) im Verzeichnis <code>\Bzr</code>. Da dies so zentral festgelegt ist, kann das Batchfile direkt darauf zugreifen. Im Start-Batchfile sind zusätzlich in lokal gültigen Umgebugsvariablen die Commit-Daten niedergelegt. Diese sind damit Working-Area-spezifisch.

Es gibt dann noch einen weiteren interessanten Batchfile:

File <code>bzre.bat</code>

@echo off
REM Add the Bzr directory to system-wide PATH environment variable
SET PATH=D:\Progs\Bazaar;%PATH%
SET USERNAME=hartmut
SET BZREMAIL=hartmut.schorrig@vishia.de
::
if not "%1" == "cd" goto :nocd
echo on
cd %2
echo off
:nocd
REM if the directory contains .bzr.bat, it is processed. It doesnt return!
REM if the directory or any parent does not contain .bzr change to the parent.
if exist .bzr.bat .bzr.bat
if not exist .bzr cd ..
if exist .bzr.bat .bzr.bat
if not exist .bzr cd ..
if exist .bzr.bat .bzr.bat
if not exist .bzr cd ..
if exist .bzr.bat .bzr.bat
echo Bazaar-Explorer: %CD%
bzrw.exe explorer .
bzr.exe version-info >_bzr_version.txt
goto :ende

:ende
exit /B

Dieses File kann entweder parameterlos gerufen werden oder mit den Parametern

bzre.bat cd aktuelles_Verzeichnis

Anhängig davon ob im angegebenen aktuellen Verzeichnis oder mehreren übergeordneten Verzeichnissen entweder ein Verzeichnis <code>.bzr</code> vorgefunden wird - das wäre also ein lokales eigenes Archiv - oder es wird ein File <code>.bzr.bat</code> vorgefunden, wird entweder der Bazaar-Explorer mit dem vorhandenen lokalen Archiv gerufen, oder es wird das oben aufgeführte <code>bzr_mvExpl.bat</code> aufgerufen, das das Archiv hin-und herkopiert. Man hat also einen Aufruf für alle vorkommenden Fälle und kann den Bazaar-Explorer unabhängig und schnell starten, ohne nachdenken und suchen zu müssen.

====Synchronisierung mehrerer Bearbeiter====

Wenn jeder sein eigenes bzr-Archiv hat und es wird gemerged, dann ist das so wie es Bazaar vorsieht.

Wenn es aber einen Hauptbearbeiter gibt und mehrere eher Nutzer dieser Sources, dann kann es auch eine File-diff-Tool-Abstimmung geben wie oben dargestellt. Man muss sich nur ab und zu in einem Netzwerk treffen. Es will nicht jeder immer und überall alle Files ändern.

==Source Content Management oder hart archivieren? Nur Quellen im SCM?==

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.

===Quellen und Generate in einem Verzeichnis ?===

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.

===Archivierung der Datenbasis des SCM===

Die Datenbasis besteht aus Files, die in üblicher Art als File-Bündel archiviert und restauriert werden können.

==Mehrere Produkte aus einem Repository==
@ident=SCM-Cmpn-de

Das große Thema ist Wiederverwendung (Reuse). Häufig zu Beobachten: Reuse besteht aus copy'n paste and change. Die Quellen wandern also irgendwo anders hin, bzgl SCM auch für den einzelnen besser zu beherrschen - man muss sich nur mit dem beschäftigen, was man selbst hat.

Das ist keine wirkliche Wiederverwendung. Der wirkliche Vorteil des reuse geht dabei verloren:
* Fehler, die in Produkten festgestellt werden, werden in den jeweiligen Modulen korrigiert und sind dann automatisch auch für andere Produkte mit korrigiert, obwohl sie dort ggf. noch gar nicht aufgefallen sind.

Für true-reuse ist es notwendig, die Software-Module so zu bauen, dass sie '''unverändert''' in verschiedenen Produkten verwendbar sind und das Änderungen für alle Produkte nutzbar sind. Das ist eine Frage der Schnittstellen. Die Schnittstellen sind viel wichtiger als die innere Funktionalität. Letztere kann man immer noch verbessern. Schnittstellenänderungen sind kritisch. - Andererseits sind Schnittstellenänderungen auch verträglich, wenn sie formell adaptiert werden können.

Ein shared-Repository in bazaar scheint die Lösung zu bieten, aus einem recht großen Quellenumfang für verschiedene Komponenten verschiedene Quellen herauslösen zu können. Die Komponenten haben selbe gemeinsame Quellen, ggf. in verschiedenen Revisionen, die aber immer abgeglichen werden können sollten. Die Komponenten sind dann Basis für ein Produkt. Komponenten existieren in Form von libs oder jars in Java und können eigenständig getestet werden:

Quellen Komponenten Produkte
viele ===> weniger ===> aus Komponenten
verschiedene überschaubar und Produkt-spezial-Quellen
gebaut.

Wie funktioniert shared-Repository als zentraler Bezug - bin beim testen. (Hartmut)
==Zentrale Ablage für Repositories==
@ident=SCM-centralRepos-de

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.

===Creating one shared repository in the local space===
The ''local space'' means any external hard disk, network folder or such which is owned by one person, by me. It is my local space, which can be used from some more people in my direct environment.

For any component of sources one shared repository should be created one time. On one sub directory per component: ''bzre: Bazaar -> Start -> Initialize: (x) Shared repository''. An existing plain branch can be pushed to them.

===Creating a branch for working===

* Create a new plain branch at the working position: ''bzre: Bazaar -> Start -> Initialize: (x) Plain branch''.
* Pull from a shared repositiory: ''Button Pull, select the shared repository, select a branch.
** If there are some files already, create the branch at a new position and then move .bzr subdir.

==Branches und dessen Auflösung==
@ident=SCM-sidebranch-en

;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.

Samba

JcHartmut — Fri, 09 Nov 2012 23:17:21 GMT

JcHartmut: Undo revision 1458 by 99.91.170.243 (Talk)

==Samba==
Used with Suse 11.3

Experiences with local network

The following informations for a share 'hartmutL' are set in the "yast - samba - shares":

* Only then a net use from a windows PC with another login works:
guest ok Yes
* Without that entry the user was 'nobody' if files are copied to linux.
force user hartmut
* ok
readonly No
path /home/hartmut
* I don't know what is it:
inherit acls No

Usage in windows:
net use //192.168.1.62/hartmutL /user:hartmut
I don't know whether the user is necessary. It is for windows-shares. Samba assigns the user on the server with 'force user' property. TODO test

Adress Line in Dolphin in another Linux computer (Ubuntu) shows the folder:
smb://192.168.1.62/hartmutL

Source-Version-Management-de

JcHartmut — Fri, 09 Nov 2012 23:15:59 GMT

JcHartmut: Navigation

==Navigation==
* up: [[Main_Page]]
* down: TODO some examples and pattern

==Source code management (SCM)==
@ident=SCM

Links:
* [[Bazaar-guide]]: a guide to use Bazaar.

This size is in german, because it is discussed in a german team. It will be presented in english in the future. TODO

==Kurzer Abriss, Arbeit mit MKSSI, git, mercurial, Bazaar==
@ident=SCM-gitCo

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 [[https://bitbucket.org/jchartmut/cruntimejavalike 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.

==Einzelne Files vs. SCM-Archiv==
@ident=SCM-Files
.
===Primat der Datenhaltung im SCM===

Ein Source Content Management (SCM) wie Bazaar, git oder andere enthält alle relevanten Files einschließlich deren Versionierung in einer eigenen internen Form (Datenbasis) gespeichert. Dem gegenüber steht der ''Working tree''. Das sind die Files mit denen man arbeitet. Der ''working tree'' lässt sich jederzeit aus dem SCM für beliebige Versionen rekonstruieren. Committet man immer auch Änderungen, dann ist der ''working tree'' temporär. Man braucht ihn nur während des Editierens, Compilierens, Makens. Danach kann er ersatzlos gelöscht werden, da alles im Archiv des SCM steht.

Damit steht das SCM im Mittelpunkt. Das ist auch in Ordnung so, da dies die entscheidende Stelle für die Versionierung der Sources ist. Diesbezüglich unterscheiden sich zentrale SCM nicht von den verteilten. Lediglich - bei einem zentralem SCM braucht man die Serveranbindung.

Die Files stehen meist als ''working tree'' solange bereit, bis man sie nach vorigem ''commit'' oder ''checkin'' löscht. Damit kann man auch bei einem zentralem SCM dezentral an den Files arbeiten, wenn auch nicht einchecken oder ältere Versionen sichten.

Die Alternative, ein File-Baum nur in direkter Verbindung mit dem SCM bereitzustellen gibt es auch. Dann sind die Files nur aufrufbar, wenn das SCM läuft. Die Files werden vom Betriebssystem dann nicht auf der Festplatte mit dem üblichen Filesystem gespeichert sondern alle Filezugriffe des Betriebssystems laufen über den SCM-Treiber. Damit sind keine Files vorhanden wenn das SCM mit seinem Archiv nicht zugänglich ist. Diese Variante ist die konsequenteste Anbindung an ein SCM, aber für eine offline-Arbeit eher schwierig und daher weniger verbreitet.

Es gibt also ein '''Primat des SCM gegenüber den Einzelfiles''', das mehr oder weniger stark ist.

===Gegenentwurf - Primat der Einzelfiles, lediglich Ablage und Austausch über das SCM===

Es ist möglich, die Hauptsicht auf die Files zu legen und das SCM nur als ''Ablage'' oder Austauschmedium zu nutzen. Die Files werden dann immer beibehalten, in das SCM wird nur eingecheckt oder committet. Das SCM hat dann den Zweck, auf Altversionen rückgreifen zu können und Versionen einfach zu vergleichen. Austauschen wird man gegebenenfalls über das SCM nur bestimmte Schnittstellenfiles, wenn die Bearbeitung sonst in einer Hand liegt.

Diese Arbeitsweise hat einen entscheidenden Nachteil: Es wird gegebenenfalls nicht bemerkt, dass wichtige Files überhaupt nicht in das SCM aufgenommen worden sind. Wenn dann keine weitere Datensicherung besteht und nur noch der Datengehalt des SCM verfügbar ist, sei es wegen einem Hardwarecrash, sei es bei Bearbeiterwechsel usw, dann kommt das Böse Erwachen. Es compiliert nicht, was fehlt...

Der andere Nachteil ist, das sich möglicherweise Alt-Files ansammeln, man löscht diese nicht aus Befürchtung, irgendwo könnten diese noch wichtig sein.

Tendiert ein Bearbeiter zu der Arbeitsweise, eher Files zu behalten und nur einzuchecken, dann muss es einen Test an anderer Stelle auf Vollständigkeit der Daten im SCM geben. Am einfachsten ist dies getan, wenn auf einem leerem PC oder Verzeichnisbaum aus dem SCM ausgecheckt wird und dort alle relevanten Makeprozesse durchlaufen werden. Laufen diese fehlerfrei und ist das Ergebnis korrekt, dann sind die Sources vollständig.

===Kompromiss - Arbeit mit Files und dem SCM===

Eine kleine Anekdote:

Seit mehr als einem Jahrzehnt läuft Software auf Anlagen. Sorry, die Welt ist nicht so schnellebig wie junge Leute heute glauben. Die Software wurde zu einer Zeit erstellt (seit 1994), zu der SCM noch nicht so gängige Praxis war. Jedoch wurde die Software in fleißiger Arbeit postum eingecheckt, prozess-konform, wie es sich ordentlich gehört. - Ein paar Jahre später, Nachbesserung von Hardware auf der Anlage, gegebenenfalls ist die Software betroffen. Mittlerweile war das SCM die "alte Version", doch selbstverständlich, man hat ja Zugänge und Archive gespeichert. 1 Tag Arbeit, und der Zugang funktioniert. Nun jedoch zeigte es sich, das zwar damals alles ordentlich eingecheckt wurde, aber nur die offensichtlichen Endstände. Da fehlte etwas, da stimmt was nicht - da war doch noch was ????. Bis ein Kollege damit herausrückte, er hat mal alle Stände auf CD direkt archiviert, die CD liegt im Schrank.

Die Files auf der CD hatten dann tatsächlich für mich als Entwickler einen hohen Wiedererkennungswert, wichtig dabei die Verzeichnisstruktur. Da die Backups von den laufenden Arbeitsstadionen gezogen worden sind, direkt ohne Zusatzaufwand als Filebaum, war eine Vollständigkeit gewährleistet. Die Zusatzarbeit des Eincheckens in das damalige SCM versionsgetreu hatte also Informationen verwässert.

Mit Diff-View auf den Files war dann schnell wieder der Überblick über den Gang der Entwicklung da. Übrigens - wenn man alles sehr fein säuberlich dokumentiert, auf 100 Seiten oder mehr, muss man dann später die 134 Seiten wieder lesen - ist auch Aufwand.

==>Über lange Jahre ist zwar ein SCM-System stabil und kritikunwürdig (ja klar), aber die Arbeit damit nicht. Zum Glück hat man dann backups der Files direkt.

==>Ein SCM ist wichtig für die zeitnahe Arbeit. Insbesondere für das Diff-View und die Nachverfolgung, wann wurde was geändert. Ohne SCM ist nicht!!! Aber die Arbeit direkt mit den Files hat auch seine Vorteile.

==Mehrere Arbeitsverzeichnisse, mehrere SCM-Archive, Wiederverwendung==

Wird Software stark wiederverwendet, dann erscheinen die gleichen Quellfiles möglicherweise innerhalb der jeweiligen Applikationen selbst beim selben Bearbeiter mehrfach.

Diese konsequente Art der Wiederverwendung ist nicht häufig anzutreffen. Wiederverwendung wird meist verstanden als ''kopiere es und pass es an''. Die konsequente Wiederverwendung - gleiche Quellen ohne Anpassung - hat den Vorteil dass Fehler oder Verbesserungen in einer Anwendung gefunden sofort auch in den anderen Anwendungen nützen. Allerdings muss man bei diesen wiederverwendeten Quellen die Unabhängigkeit von der jeweiligen Applikation beachten. Eigentlich eine konsequente Softwaretechnologie.

Werden die Quellen mehrfach für verschiedene Applikationen benutzt, dann kann nicht vorausgesetzt werden, dass alle Projekte mit einem einheitlichen Stand der Quellen arbeiten. Wünschenswert ist es zwar, dass an allen Stellen mit der selben Version gearbeitet wird, eben wegen der Vorteile. Andererseits kann aber eine Änderung in einer Applikation zwar allgemeingültig erfolgen, jedoch nicht fehlerfrei und allgemeingültig genug. In einer anderen Applikation können sich Folgefehler ergeben, die erst gefunden und getestet werden müssen. Ergebnis dessen ist zwar eine verbesserte Allgemeingültigkeit, jedoch ist dies mit Arbeit verbunden. Für Bugfixes aus Sicht einer Anwendung werden sich daher Differenzen nicht vermeiden lassen.

Damit sind möglicherweise Seitenzweige im Archiv des SCM erforderlich. Andererseits sollte ein Zuviel an Seitenzweigen vermieden werden, besser ist es jeweils nach Korrekturen den Hauptzweig anzuwenden. Die Seitenzweige sollten eher temporärer Natur sein.

Das SCM Bazaar unterstützt Seitenzweige mit automatisch unterstütztem merge.

===Vermeiden von Seitenzweigen bei Änderungen gemeinsamer Quellen für verschiedene Anwendungen zeitlich nacheinander===

Um Seitenzweige zu vermeiden, kann sich folgende Vorgehensweise als geeignet erweisen:

* Angenommen, eine Applikation A verwendet die Hauptversion 123.

* In einer anderen Applikation B werden in einer gemeinsamen Source-Komponente Verbesserungen vorgenommen. Damit entsteht letzlich die Hauptverson 137.

* Nun wird versucht, die Hauptversion 137 auch in A anzuwenden. Angenommen, es gibt Anpassungsnotwendigkeiten, die sich erst aus Sicht der Applikation A zeigen aber insgesamt die gemeinsame Komponente aufwerten. Es entsteht Hauptversion 139.

* Nun sollte diese Hauptversion auch für B anwendbar sein. Hat man Schnittstellen gut definiert, dann sollte es nicht unbedingt schon wieder Komplikationen geben. Es bleibt also bei der 139.

* Das Ganze soll nun auch für weitere Applikationen passen. Eventuell sind wiederum Anpassarbeiten notwendig.

Werden die Anpassungen nicht nacheinander sondern parallel ausgeführt, von verschiedenen Bearbeitern, dann entstehen zwischendurch Seitenzweige, die jeweils wieder bereinigt werden müssen. Diese Bereinigungen sind teils mergen, teils Schnittstellen klarer formulieren, teils Verbesserungen für allgemeingültige Verwendung. Es ist nun günstig, diese Bereinigungen in einer Referenzapplikation zentralisiert auszuführen. Der Test, ob die Ergebnisse bei den einzelnen Applikationen passt, ist dann wieder dezentralisiert.

Verwendet man Bazaar, dann entstehen dezentralisiert divergierende Versionen. Diese in einem Baum zusammenzufassen kann sich gegebenenfalls als nicht zweckmäßig erweisen. Gegebenenfalls ist es besser, in der zentralisierten Bearbeitung der Komponente mit der Referenzapplikation zwar alle Inputs zu verwerten, aber nicht auch alle nuancierte Änderungen im Original zu berücksichtigen. Oft ist ein Austausch - eine kompatible aber bessere Variante - die einfache Lösung, die auch Zufriedenheit bei den einzelnen Applikationen auslöst.

Damit ergibt sich allerdings die Situation, dass das formelle Arbeiten mit den Bazaar-Archiven nicht funktioniert. Denn:

* Applikation A hat ihre Version 125 abgegeben (merge-Input), die eine Verbesserung der zuvor erhaltenen (poll) Version 123 darstellt.

* Applikation B hat aber in ihrer Version 137 aus der gemeinsamen Versionen 123 hervorgegangen möglicherweise adäquate aber nicht gleiche Lösungen gefunden, die auch der Verbesserung in A entsprechen.

* Die zentralisierte Bereinigung entschließt sich daher, zwar die Funktionalität von A in 125 in der Nachbearbeitung zu garantieren, enthält aber nicht formell den Versionsstand 125 von A. Die nachbearbeitete Komponente wird also als Version 137 wieder der Applikation A angeboten, jedoch nicht passend in Archivbaum, der in A verwendet wird.

* A muss nun einerseits möglichst positiv entscheiden, dass die Änderungen zu Version 137 überhaupt benutzt werden. Die positive Entscheidung bedeutet die Fortsetzung der Partizipation an der Weiterentwicklung in der Zukunft. Andererseits muss A den Aufwand treiben, zu testen, dass es keine negativen Auswirkungen gibt.

* Formell kann die Applikation A nicht das bisherige SCM-Archiv einfach updaten, da die eigene letzte Version nicht enthalten ist.

* Zielführender ist es, nun auf der Basis der Sichtung der Differenzen der Files zu entscheiden, welche Tests ausgeführt werden müssen und welche Auswirkungen zu erwarten sind. Möglicherweise findet sich die Funktionalität der ursprünglichen Verbesserung 125 in A in nur in wenigen Zeilen nicht identisch aber passend ausgeführt. Alle anderen Änderungen sind nicht relevant da sie nicht verwendete Funktionen betreffen. Es ist also auf Basis der File-Differenz-Sichtung leicht zu entscheiden, dass nunmehr auf der neuen Version 137 aufgesetzt wird.

* Das SCM-Archiv kann nun in der Applikation A neu importiert werden, das alte Archiv wird gelöscht. Es enthielt zwar die Änderungen von 123 auf 125, die sich im neuen Archiv nicht finden, angenommenerweise ist diese Version 125 in A aber nicht pflegerelevant.

Dieses Szenario kann durchaus als typisch bezeichnet werden. Die meisten Änderungen werden kompatibel vorgenommen oder treffen nicht für alle Applikationen zu, wenn sorgsam in der Komponentenentwicklung gearbeitet wird.

Damit verschiebt sich allerdings die '''Sicht vom Primat des SCM-Archivs auf das Primat der Files'''. Zumindestens während des Überganges der Nutzung der neuen Hauptversion 137.

Wie sollte konkret umgegangen werden:

* Die neue Hauptversion 137 der Komponente wird aus dem erhaltenem SCM-Archiv auf einer unabhängigen Stelle im Filesystem als Workingtree exportiert. Die Files der Komponente in der Applikation werden nicht geändert.

* Nun erfolgt der Einzelfilevergleich zwischen dem neuen Workingtree und den bestehenden Files. Selbstverständlich sind dabei die Einträge im Log des SCM-Archives für das Verständnis der Änderungen wichtig. Letzlich werden aber die Inhalte der Files auf Passfähigkeit begutachtet.

* Im zweiten Schritt werden die neuen Files als File, nicht über das SCM-Archiv in die bisherige Applikation kopiert und die im alten aber nicht im neuen Archiv befindliche Files werden gelöscht. Letzteres ist wesentlich und typisch wenn in der Komponente umstrukturiert wurde. Das bisherige Archiv, im Beispiel auf der 125 stehend, wird erstmal weiterverwendet. Der neue Stand wird also als 126 committet.

* Danach erfolgt der Test von A.

* Im Idealfall passt alles. Es gibt keine Änderungen. Etwas weniger ideal aber erwartbar ist, dass der Stand der Komponente 137 vollständig akzeptierbar ist, allerdings sind kleine Nachbesserungen in der Applikation notwendig.

* In diesen beiden Fällen kann dann das Archiv ausgetauscht werden. Das alte SCM-Archiv mit den Versionsständen 123, 125 und zuletzt 126 wird entfernt, statt dessen das gelieferte Archiv mit der 137 eingesetzt. Im Archiv kann dann nachgelesen werden, welche Änderungen es insgesamt in der Komponente gab, auch wenn sich diese nicht aus der Applikation A ergeben hatten. Möglicherweise sind diese Änderungen für die Weiterentwicklung von A interessant oder wichtig.

Der Fall der notwendigen Nachbesserung in der Komponente, weil die Funktionalität in A nicht passt, erfordert den oben beispielhaft dargestellten Zyklus der Nachbesserung in der Komponente mit notwendigem Aufwand wiederum für alle Applikationen. Entweder dieser Aufwand ist gerechtfertigt oder möglich. Oder nach entsprechenden Klärungen ordnet sich die Applikation A dem gegebenen Stand der Komponente unter, oder mindestens vorerst wird weiter mit der eigenen Variante A gefahren.

* Konkret kann dabei auf der neu gelieferten Version 137 mit neuem Archiv aufgesetzt werden: Dort werden die notwendigen Änderungen vorgenommen und das ganze wird als neuer Versionsstand 138 aus Sicht der Applikation A an die zentrale Komponentenentwicklung zurückgeliefert.

* Der Zyklus beginnt damit erneut, hoffentlich mit kleinen und kompatibel ausführbaren Änderungen, die für eine Beruhigung der Zyklen sorgt.

===Überblick über die Anzahl Archive für die selbe Softwarekomponente ?===

Die Kapitelüberschrift ist mit einem Fragezeichen versehen.

Angenommen, es gibt etwa 10+x Stellen, an denen die selbe Softwarekomponente eingesetzt wird. Das kann sich auf mehrere PCs und Bearbeiter verteilen, auch auf dem selben PC mag es mehrere Stellen geben, weil die Softwarekomponente eben in verschiedenen Applikationen drinsteckt.

Bazaar sieht nun vor, an jedem Working tree ein eigenes Archiv zu haben. Man kann mit Bazaar-Bordmitteln dann pushen, pullen, mergen jeweils mit einem anderen Archiv. Insbesondere kann an jedem Archiv auch ein 'submit-branch'' angegeben werden (Settings - configuration - branch). Damit kann unaufwändig ein etwas zentraleres Archiv angesprochen und beobachtet werden.

Dennoch, bei 10+x Archiven, die sich gut gegeneinander updaten lassen, können sich Unterschiede breitmachen und Merge-Aufwand erzeugen, die überhaupt nicht gewünscht sind. Außerdem kann man leicht den Überblick verlieren, wo denn überhaupt welche Bearbeitung stattgefunden hat. Beim Mergen muss man dann erst einmal überlegen, was denn die bessere Version ist. Damit artet das Ganze in Arbeit aus, die man doch vermeiden und verbessern wollte ....

Die Arbeit mit einem zentralen Archiv gestaltet sich dann einfacher, wenn das es eigentlich nur einen Hauptzweig gibt und Unterschiede vermieden werden sollen. Unterschiede entstehen eigentlich eher unerwünscht bei Parallelarbeiten und sind möglichst schnell wieder abzustellen.

Es soll hier aber nicht den zentralen Archiven das Wort geredet werden. Der Vorteil der dezentralen Archive ist gerade ein gewisses unabhängiges Arbeiten und eine gute Merge-Unterstützung. Jedoch - total denzentral kann auch zuviel des Guten sein.

Zweckdienlich kann es sein, für einen Bearbeiter auf einem PC nur ein Archiv zu halten. Voraussetzung dafür ist aber, das alle Applikationen tatsächlich immer mit den gleichen Source-Versionsstand compiliert werden sollen. Ich habe auf einem PC auch nur eine Entwicklungsumgebung (Eclipse für Java), in der alle Quellen für alle Projekte eingebunden sind. Damit ist es bei Strukturänderungen relativ einfach, die automatischen Möglichkeiten des Tools zu nutzen (renaming, wird automatisch in allen sichtbaren Quellen nachgezogen). Außerdem gewinnt man bei möglicherweise problematisch inkompatiblen Änderungen sofort den Überblick, wo es klemmen könnte. Es wird jeweils alles compiliert. Diese Arbeitsweise hat sich bewährt.

Dennoch, für die einzelnen Applikationen gibt es bei mir verschiedene Stellen im Filesystem (Working area). Wichtig ist, dass eine Änderung eben gerade ausgeführt mit Auswirkungen auf Applikation X zwar formell compilierfähig ist aber damit noch nicht getestet, sich nicht sofort auf einen Auslieferungsstand mit Feinkorrektur auswirkt. An diesen Stellen compiliere ich mit einem Batch-Aufruf. Das ist einfacher. Beim Batch-Aufruf werden die Files in der Working-Area benutzt. Bei einer Feinkorrektur braucht es keinen entwicklungsumgebungsunterstützten Test mit Schritt-Debugging usw. Die Korrektur wird textuell ausgeführt, compiliert und zur Laufzeit getestet.

Ein Gesamttest wird aber in dem zentralem Eclipse-Projekt mit zentralisierten Files. Damit wird immer auf dem letzten Stand basierend getestet. Von dieser zentralisierter Working-Area wird dann das Archiv (Bazaar) gepflegt, von dort wird committed.

Wie kommt aber nun eine Detailänderung aus einer denzentralen Workingarea in das Archiv? Wie kommt der letzte Archivstand in die dezentrale Working-Area?

Für die zweite Frage gäbe es eine Antwort:

bzr export %DST% --per-file-timestamps -r %REVISION%

Damit werden nur Files nach %DST% kopiert, sogar mit dem originalem Datum (geht nicht bei Unix), optional mit einer angegebenen Revisionskennzeichnung. Aber: Das ist ein blindes kopieren. Man sieht nicht vorher, welche Änderungen sich damit ergeben. Man übersieht und überschreibt für immer Änderungen in der Workingarea. "bzr export" eignet sich für die Erstellung einer neuen workingarea ohne Archivanbindung, nicht aber für's updaten.

Die ggf. bessere Variante liegt außerhalb des SCM, nämlich bei den altbewährten '''File-Baum-Diff-Tools'''. Da gibt es eine Menge, jeder hat seine gewohnten Tools, diese haben sich bewährt. Man kann die Unterschiede per File-Vergleich sichten und damit übersichtlich entscheiden, ob eine Änderung denn überhaupt wesentlich ist, was eine andere Änderung an Nebeneffekten bewirken könnte usw. usf. Ein Merge mit bazaar ist zwar auch ganz gut, aber es erzeugt zuerst Seitenversionen, bei denen man im Nachhinein (!) dann feststellt, dass das eigentlich unerwünschte oder unnötige Seitenzweigänderungen sind. Damit sind diese aber schon im Archiv manifestiert, haben Datenmüll erzeugt und müssen dann zusätzlich im Nachhinein wieder ausgebessert werden (Anschauen, löschen von *.THIS, *.BASE und *.OTher). Die Arbeit kann man sich sparen.

Die Lösung wäre also hier: Ein Archiv (pro PC) mit dem Haupt-Workingtree aus Haupt-Workingarea, '''manuelles Abstimmen von Files in den einzelnen Workingareas''' für die jeweiligen Applikationen. Man kann in diesem Zusammenhang "bzr export" nutzen um letzlich genau den Archivstand in eine Applikations-Workingarea hineinzulegen. Zuvor sollte die Workingarea gelöscht bzw. besser parallel gesichert und danach gelöscht werden. Erfolgt das löschen nicht, dann besteht die Gefahr, dass in der Applkations-Workingarea Files liegen, die wichtig für die Applikation sind, sich aber nicht im SCM-Archiv befinden. Das sollte unbedingt kontrolliert und vermieden werden. Wird zuerst per "move"- Befehl gelöscht und gesichert, danach die Files per "bzr export" neu eingespielt und danach compiliert, dann fallen diese Fehler auf. Bei Problemen kann man auf die gesichrten Files zurückgreifen. Letztlich sollte die Sicherung aber vernichtet werden, da sie sonst auch wieder nur Datenmüll ist.

Es gibt noch eine andere Möglichkeit des Bindens nur eines Archives an mehrere Working-Areas:

Unter Linux kann ein symbolischer Link <code>bzr.</code> auf das Archiv gelegt werden. Das Archiv muss dabei auf demselben Datenträger stehen, einige Funktionalitäten in Bazaar gehen sonst nicht. Aber es kann zentral irgendwo anders stehen. Mehrere symbolische Links können auf das selbe Archiv zeigen.

Nun kann man damit
* ''commit'' von verschiedenen Working-Areas ausführen und trifft jeweils das selbe Archiv. Die committeten Files erscheinen damit im Archiv, nicht jedoch automatisch in den anderen Working-Areas!
* den Filebaum betrachten und feststellen, welche Änderungen im Archiv passiert sind, die nicht aus dieser Workingarea stammmen. Man kann sich über die Bazaar-GUI die Differenzen anzeigen. Da Bazaar diese Arbeitsweise so nicht vorsieht, präsentieren sich die Änderungen spielelverkehrt. Geänderte Files mit neuem Stand im Archiv erscheinen als ''commitwürdig'' der alten Files. Neue Files im Archiv erscheinen als ''deleted files''. Um hier zu unterscheiden, was denn Änderungen in der speziellen Working Area sind, muss man schon die eigenen Files kennen. Dabei hilft ein kleines Backup des letzten Standes aus dem SCM, auf dem aufgesetzt worden ist, dabei wieder mit File-Diff-View außerhalb des SCM - nur um die eigenen Änderungen zu erkennen. Das ist damit eindeutig. File-Diff-Tools können teils auch direkt in Zip-Archiven arbeiten. Man benötigt also nur ein einfaches Zip-Backup angelegt bevor man in der speziellen Working area losarbeitet. Man kann auch postum über ein "bzr export" den Ausgangstand wieder erzeugen.
* committen einzelner Files, die nur in dieser Working Area geändert worden sind.
* Zuletzt über

bzr revert

*+den Stand aus dem SCM-Archiv in die working-Area hinein synchronisieren um wieder einen gemeinsamen Ausgangsstand zu haben.

Unter Windows geht das mit dem symbolischen Link nicht. Man kann aber stattdessen mit einem move-Befehl das Archiv von einem Platz auf einen anderen Hin- und Herschieben. Es sollte zuletzt immer auf dem zentralen Platz wieder landen, sonst weiß man nicht wo es aktuell steht. Der <code>move</code>-Befehl kopiert nicht die Archiv-Files auf der Festplatte sondern ändert tatsächlich nur einen Verzeichniseintrag. Das ist also von der Belastung der Festplatte und vom Zeitaufwand her gesehen sehr billig. Vorraussetzung: Selbe Partition der Festplatte!

Ich habe dazu folgende Befehlsfolge in einem zentralen Batch-File niederlegt:

File <code>bzr_mvExpl.bat</code>

set CMPN=%1
REM Add the Bzr directory to system-wide PATH environment variable
SET PATH=D:\Progs\Bazaar;%PATH%
attrib -h \Bzr\%CMPN%\.bzr
if not exist .bzr move \Bzr\%CMPN%\.bzr .bzr
echo Bazaar-Explorer:
bzrw.exe explorer .
bzr.exe version-info >_bzr_version.txt
if not exist \Bzr\%CMPN%\.bzr move .bzr \Bzr\%CMPN%
attrib +h \Bzr\%CMPN%\.bzr

Wichtig für das funktionieren des move-Befehls ist das Rücksetzen des Hidden-Attributes für das .bzr-Archiv.

Dieses File wird in einem File im Arbeitsverzeichnis (Working Area)

.bzr.bat

mit drei Zeilen

SET USERNAME=hartmut
SET BZREMAIL=hartmut.schorrig@vishia.de
bzr_mvExpl.bat srcJava_vishiaBase

aufgerufen. Das <code>srcJava_vishiaBase</code> ist hierbei der Name der Softwarekomponente und der Name des Verzeichnisses in dem das <code>.bzr</code>-Archiv steht. Alle <code>.bzr</code>-Archive stehen dabei zentral auf der selben Festplatte (keine Laufwerksangabe am Pfad) im Verzeichnis <code>\Bzr</code>. Da dies so zentral festgelegt ist, kann das Batchfile direkt darauf zugreifen. Im Start-Batchfile sind zusätzlich in lokal gültigen Umgebugsvariablen die Commit-Daten niedergelegt. Diese sind damit Working-Area-spezifisch.

Es gibt dann noch einen weiteren interessanten Batchfile:

File <code>bzre.bat</code>

@echo off
REM Add the Bzr directory to system-wide PATH environment variable
SET PATH=D:\Progs\Bazaar;%PATH%
SET USERNAME=hartmut
SET BZREMAIL=hartmut.schorrig@vishia.de
::
if not "%1" == "cd" goto :nocd
echo on
cd %2
echo off
:nocd
REM if the directory contains .bzr.bat, it is processed. It doesnt return!
REM if the directory or any parent does not contain .bzr change to the parent.
if exist .bzr.bat .bzr.bat
if not exist .bzr cd ..
if exist .bzr.bat .bzr.bat
if not exist .bzr cd ..
if exist .bzr.bat .bzr.bat
if not exist .bzr cd ..
if exist .bzr.bat .bzr.bat
echo Bazaar-Explorer: %CD%
bzrw.exe explorer .
bzr.exe version-info >_bzr_version.txt
goto :ende

:ende
exit /B

Dieses File kann entweder parameterlos gerufen werden oder mit den Parametern

bzre.bat cd aktuelles_Verzeichnis

Anhängig davon ob im angegebenen aktuellen Verzeichnis oder mehreren übergeordneten Verzeichnissen entweder ein Verzeichnis <code>.bzr</code> vorgefunden wird - das wäre also ein lokales eigenes Archiv - oder es wird ein File <code>.bzr.bat</code> vorgefunden, wird entweder der Bazaar-Explorer mit dem vorhandenen lokalen Archiv gerufen, oder es wird das oben aufgeführte <code>bzr_mvExpl.bat</code> aufgerufen, das das Archiv hin-und herkopiert. Man hat also einen Aufruf für alle vorkommenden Fälle und kann den Bazaar-Explorer unabhängig und schnell starten, ohne nachdenken und suchen zu müssen.

====Synchronisierung mehrerer Bearbeiter====

Wenn jeder sein eigenes bzr-Archiv hat und es wird gemerged, dann ist das so wie es Bazaar vorsieht.

Wenn es aber einen Hauptbearbeiter gibt und mehrere eher Nutzer dieser Sources, dann kann es auch eine File-diff-Tool-Abstimmung geben wie oben dargestellt. Man muss sich nur ab und zu in einem Netzwerk treffen. Es will nicht jeder immer und überall alle Files ändern.

==Source Content Management oder hart archivieren? Nur Quellen im SCM?==

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.

===Quellen und Generate in einem Verzeichnis ?===

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.

===Archivierung der Datenbasis des SCM===

Die Datenbasis besteht aus Files, die in üblicher Art als File-Bündel archiviert und restauriert werden können.

==Mehrere Produkte aus einem Repository==
@ident=SCM-Cmpn-de

Das große Thema ist Wiederverwendung (Reuse). Häufig zu Beobachten: Reuse besteht aus copy'n paste and change. Die Quellen wandern also irgendwo anders hin, bzgl SCM auch für den einzelnen besser zu beherrschen - man muss sich nur mit dem beschäftigen, was man selbst hat.

Das ist keine wirkliche Wiederverwendung. Der wirkliche Vorteil des reuse geht dabei verloren:
* Fehler, die in Produkten festgestellt werden, werden in den jeweiligen Modulen korrigiert und sind dann automatisch auch für andere Produkte mit korrigiert, obwohl sie dort ggf. noch gar nicht aufgefallen sind.

Für true-reuse ist es notwendig, die Software-Module so zu bauen, dass sie '''unverändert''' in verschiedenen Produkten verwendbar sind und das Änderungen für alle Produkte nutzbar sind. Das ist eine Frage der Schnittstellen. Die Schnittstellen sind viel wichtiger als die innere Funktionalität. Letztere kann man immer noch verbessern. Schnittstellenänderungen sind kritisch. - Andererseits sind Schnittstellenänderungen auch verträglich, wenn sie formell adaptiert werden können.

Ein shared-Repository in bazaar scheint die Lösung zu bieten, aus einem recht großen Quellenumfang für verschiedene Komponenten verschiedene Quellen herauslösen zu können. Die Komponenten haben selbe gemeinsame Quellen, ggf. in verschiedenen Revisionen, die aber immer abgeglichen werden können sollten. Die Komponenten sind dann Basis für ein Produkt. Komponenten existieren in Form von libs oder jars in Java und können eigenständig getestet werden:

Quellen Komponenten Produkte
viele ===> weniger ===> aus Komponenten
verschiedene überschaubar und Produkt-spezial-Quellen
gebaut.

Wie funktioniert shared-Repository als zentraler Bezug - bin beim testen. (Hartmut)
==Zentrale Ablage für Repositories==
@ident=SCM-centralRepos-de

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.

===Creating one shared repository in the local space===
The ''local space'' means any external hard disk, network folder or such which is owned by one person, by me. It is my local space, which can be used from some more people in my direct environment.

For any component of sources one shared repository should be created one time. On one sub directory per component: ''bzre: Bazaar -> Start -> Initialize: (x) Shared repository''. An existing plain branch can be pushed to them.

===Creating a branch for working===

* Create a new plain branch at the working position: ''bzre: Bazaar -> Start -> Initialize: (x) Plain branch''.
* Pull from a shared repositiory: ''Button Pull, select the shared repository, select a branch.
** If there are some files already, create the branch at a new position and then move .bzr subdir.

==Branches und dessen Auflösung==
@ident=SCM-sidebranch-en

;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.

Source-Version-Management-de

JcHartmut — Fri, 09 Nov 2012 23:08:33 GMT

JcHartmut: bzr_mvExpl.bat

==Source code management (SCM)==
@ident=SCM

Links:
* [[Bazaar-guide]]: a guide to use Bazaar.

This size is in german, because it is discussed in a german team. It will be presented in english in the future. TODO

==Kurzer Abriss, Arbeit mit MKSSI, git, mercurial, Bazaar==
@ident=SCM-gitCo

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 [[https://bitbucket.org/jchartmut/cruntimejavalike 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.

==Einzelne Files vs. SCM-Archiv==
@ident=SCM-Files
.
===Primat der Datenhaltung im SCM===

Ein Source Content Management (SCM) wie Bazaar, git oder andere enthält alle relevanten Files einschließlich deren Versionierung in einer eigenen internen Form (Datenbasis) gespeichert. Dem gegenüber steht der ''Working tree''. Das sind die Files mit denen man arbeitet. Der ''working tree'' lässt sich jederzeit aus dem SCM für beliebige Versionen rekonstruieren. Committet man immer auch Änderungen, dann ist der ''working tree'' temporär. Man braucht ihn nur während des Editierens, Compilierens, Makens. Danach kann er ersatzlos gelöscht werden, da alles im Archiv des SCM steht.

Damit steht das SCM im Mittelpunkt. Das ist auch in Ordnung so, da dies die entscheidende Stelle für die Versionierung der Sources ist. Diesbezüglich unterscheiden sich zentrale SCM nicht von den verteilten. Lediglich - bei einem zentralem SCM braucht man die Serveranbindung.

Die Files stehen meist als ''working tree'' solange bereit, bis man sie nach vorigem ''commit'' oder ''checkin'' löscht. Damit kann man auch bei einem zentralem SCM dezentral an den Files arbeiten, wenn auch nicht einchecken oder ältere Versionen sichten.

Die Alternative, ein File-Baum nur in direkter Verbindung mit dem SCM bereitzustellen gibt es auch. Dann sind die Files nur aufrufbar, wenn das SCM läuft. Die Files werden vom Betriebssystem dann nicht auf der Festplatte mit dem üblichen Filesystem gespeichert sondern alle Filezugriffe des Betriebssystems laufen über den SCM-Treiber. Damit sind keine Files vorhanden wenn das SCM mit seinem Archiv nicht zugänglich ist. Diese Variante ist die konsequenteste Anbindung an ein SCM, aber für eine offline-Arbeit eher schwierig und daher weniger verbreitet.

Es gibt also ein '''Primat des SCM gegenüber den Einzelfiles''', das mehr oder weniger stark ist.

===Gegenentwurf - Primat der Einzelfiles, lediglich Ablage und Austausch über das SCM===

Es ist möglich, die Hauptsicht auf die Files zu legen und das SCM nur als ''Ablage'' oder Austauschmedium zu nutzen. Die Files werden dann immer beibehalten, in das SCM wird nur eingecheckt oder committet. Das SCM hat dann den Zweck, auf Altversionen rückgreifen zu können und Versionen einfach zu vergleichen. Austauschen wird man gegebenenfalls über das SCM nur bestimmte Schnittstellenfiles, wenn die Bearbeitung sonst in einer Hand liegt.

Diese Arbeitsweise hat einen entscheidenden Nachteil: Es wird gegebenenfalls nicht bemerkt, dass wichtige Files überhaupt nicht in das SCM aufgenommen worden sind. Wenn dann keine weitere Datensicherung besteht und nur noch der Datengehalt des SCM verfügbar ist, sei es wegen einem Hardwarecrash, sei es bei Bearbeiterwechsel usw, dann kommt das Böse Erwachen. Es compiliert nicht, was fehlt...

Der andere Nachteil ist, das sich möglicherweise Alt-Files ansammeln, man löscht diese nicht aus Befürchtung, irgendwo könnten diese noch wichtig sein.

Tendiert ein Bearbeiter zu der Arbeitsweise, eher Files zu behalten und nur einzuchecken, dann muss es einen Test an anderer Stelle auf Vollständigkeit der Daten im SCM geben. Am einfachsten ist dies getan, wenn auf einem leerem PC oder Verzeichnisbaum aus dem SCM ausgecheckt wird und dort alle relevanten Makeprozesse durchlaufen werden. Laufen diese fehlerfrei und ist das Ergebnis korrekt, dann sind die Sources vollständig.

===Kompromiss - Arbeit mit Files und dem SCM===

Eine kleine Anekdote:

Seit mehr als einem Jahrzehnt läuft Software auf Anlagen. Sorry, die Welt ist nicht so schnellebig wie junge Leute heute glauben. Die Software wurde zu einer Zeit erstellt (seit 1994), zu der SCM noch nicht so gängige Praxis war. Jedoch wurde die Software in fleißiger Arbeit postum eingecheckt, prozess-konform, wie es sich ordentlich gehört. - Ein paar Jahre später, Nachbesserung von Hardware auf der Anlage, gegebenenfalls ist die Software betroffen. Mittlerweile war das SCM die "alte Version", doch selbstverständlich, man hat ja Zugänge und Archive gespeichert. 1 Tag Arbeit, und der Zugang funktioniert. Nun jedoch zeigte es sich, das zwar damals alles ordentlich eingecheckt wurde, aber nur die offensichtlichen Endstände. Da fehlte etwas, da stimmt was nicht - da war doch noch was ????. Bis ein Kollege damit herausrückte, er hat mal alle Stände auf CD direkt archiviert, die CD liegt im Schrank.

Die Files auf der CD hatten dann tatsächlich für mich als Entwickler einen hohen Wiedererkennungswert, wichtig dabei die Verzeichnisstruktur. Da die Backups von den laufenden Arbeitsstadionen gezogen worden sind, direkt ohne Zusatzaufwand als Filebaum, war eine Vollständigkeit gewährleistet. Die Zusatzarbeit des Eincheckens in das damalige SCM versionsgetreu hatte also Informationen verwässert.

Mit Diff-View auf den Files war dann schnell wieder der Überblick über den Gang der Entwicklung da. Übrigens - wenn man alles sehr fein säuberlich dokumentiert, auf 100 Seiten oder mehr, muss man dann später die 134 Seiten wieder lesen - ist auch Aufwand.

==>Über lange Jahre ist zwar ein SCM-System stabil und kritikunwürdig (ja klar), aber die Arbeit damit nicht. Zum Glück hat man dann backups der Files direkt.

==>Ein SCM ist wichtig für die zeitnahe Arbeit. Insbesondere für das Diff-View und die Nachverfolgung, wann wurde was geändert. Ohne SCM ist nicht!!! Aber die Arbeit direkt mit den Files hat auch seine Vorteile.

==Mehrere Arbeitsverzeichnisse, mehrere SCM-Archive, Wiederverwendung==

Wird Software stark wiederverwendet, dann erscheinen die gleichen Quellfiles möglicherweise innerhalb der jeweiligen Applikationen selbst beim selben Bearbeiter mehrfach.

Diese konsequente Art der Wiederverwendung ist nicht häufig anzutreffen. Wiederverwendung wird meist verstanden als ''kopiere es und pass es an''. Die konsequente Wiederverwendung - gleiche Quellen ohne Anpassung - hat den Vorteil dass Fehler oder Verbesserungen in einer Anwendung gefunden sofort auch in den anderen Anwendungen nützen. Allerdings muss man bei diesen wiederverwendeten Quellen die Unabhängigkeit von der jeweiligen Applikation beachten. Eigentlich eine konsequente Softwaretechnologie.

Werden die Quellen mehrfach für verschiedene Applikationen benutzt, dann kann nicht vorausgesetzt werden, dass alle Projekte mit einem einheitlichen Stand der Quellen arbeiten. Wünschenswert ist es zwar, dass an allen Stellen mit der selben Version gearbeitet wird, eben wegen der Vorteile. Andererseits kann aber eine Änderung in einer Applikation zwar allgemeingültig erfolgen, jedoch nicht fehlerfrei und allgemeingültig genug. In einer anderen Applikation können sich Folgefehler ergeben, die erst gefunden und getestet werden müssen. Ergebnis dessen ist zwar eine verbesserte Allgemeingültigkeit, jedoch ist dies mit Arbeit verbunden. Für Bugfixes aus Sicht einer Anwendung werden sich daher Differenzen nicht vermeiden lassen.

Damit sind möglicherweise Seitenzweige im Archiv des SCM erforderlich. Andererseits sollte ein Zuviel an Seitenzweigen vermieden werden, besser ist es jeweils nach Korrekturen den Hauptzweig anzuwenden. Die Seitenzweige sollten eher temporärer Natur sein.

Das SCM Bazaar unterstützt Seitenzweige mit automatisch unterstütztem merge.

===Vermeiden von Seitenzweigen bei Änderungen gemeinsamer Quellen für verschiedene Anwendungen zeitlich nacheinander===

Um Seitenzweige zu vermeiden, kann sich folgende Vorgehensweise als geeignet erweisen:

* Angenommen, eine Applikation A verwendet die Hauptversion 123.

* In einer anderen Applikation B werden in einer gemeinsamen Source-Komponente Verbesserungen vorgenommen. Damit entsteht letzlich die Hauptverson 137.

* Nun wird versucht, die Hauptversion 137 auch in A anzuwenden. Angenommen, es gibt Anpassungsnotwendigkeiten, die sich erst aus Sicht der Applikation A zeigen aber insgesamt die gemeinsame Komponente aufwerten. Es entsteht Hauptversion 139.

* Nun sollte diese Hauptversion auch für B anwendbar sein. Hat man Schnittstellen gut definiert, dann sollte es nicht unbedingt schon wieder Komplikationen geben. Es bleibt also bei der 139.

* Das Ganze soll nun auch für weitere Applikationen passen. Eventuell sind wiederum Anpassarbeiten notwendig.

Werden die Anpassungen nicht nacheinander sondern parallel ausgeführt, von verschiedenen Bearbeitern, dann entstehen zwischendurch Seitenzweige, die jeweils wieder bereinigt werden müssen. Diese Bereinigungen sind teils mergen, teils Schnittstellen klarer formulieren, teils Verbesserungen für allgemeingültige Verwendung. Es ist nun günstig, diese Bereinigungen in einer Referenzapplikation zentralisiert auszuführen. Der Test, ob die Ergebnisse bei den einzelnen Applikationen passt, ist dann wieder dezentralisiert.

Verwendet man Bazaar, dann entstehen dezentralisiert divergierende Versionen. Diese in einem Baum zusammenzufassen kann sich gegebenenfalls als nicht zweckmäßig erweisen. Gegebenenfalls ist es besser, in der zentralisierten Bearbeitung der Komponente mit der Referenzapplikation zwar alle Inputs zu verwerten, aber nicht auch alle nuancierte Änderungen im Original zu berücksichtigen. Oft ist ein Austausch - eine kompatible aber bessere Variante - die einfache Lösung, die auch Zufriedenheit bei den einzelnen Applikationen auslöst.

Damit ergibt sich allerdings die Situation, dass das formelle Arbeiten mit den Bazaar-Archiven nicht funktioniert. Denn:

* Applikation A hat ihre Version 125 abgegeben (merge-Input), die eine Verbesserung der zuvor erhaltenen (poll) Version 123 darstellt.

* Applikation B hat aber in ihrer Version 137 aus der gemeinsamen Versionen 123 hervorgegangen möglicherweise adäquate aber nicht gleiche Lösungen gefunden, die auch der Verbesserung in A entsprechen.

* Die zentralisierte Bereinigung entschließt sich daher, zwar die Funktionalität von A in 125 in der Nachbearbeitung zu garantieren, enthält aber nicht formell den Versionsstand 125 von A. Die nachbearbeitete Komponente wird also als Version 137 wieder der Applikation A angeboten, jedoch nicht passend in Archivbaum, der in A verwendet wird.

* A muss nun einerseits möglichst positiv entscheiden, dass die Änderungen zu Version 137 überhaupt benutzt werden. Die positive Entscheidung bedeutet die Fortsetzung der Partizipation an der Weiterentwicklung in der Zukunft. Andererseits muss A den Aufwand treiben, zu testen, dass es keine negativen Auswirkungen gibt.

* Formell kann die Applikation A nicht das bisherige SCM-Archiv einfach updaten, da die eigene letzte Version nicht enthalten ist.

* Zielführender ist es, nun auf der Basis der Sichtung der Differenzen der Files zu entscheiden, welche Tests ausgeführt werden müssen und welche Auswirkungen zu erwarten sind. Möglicherweise findet sich die Funktionalität der ursprünglichen Verbesserung 125 in A in nur in wenigen Zeilen nicht identisch aber passend ausgeführt. Alle anderen Änderungen sind nicht relevant da sie nicht verwendete Funktionen betreffen. Es ist also auf Basis der File-Differenz-Sichtung leicht zu entscheiden, dass nunmehr auf der neuen Version 137 aufgesetzt wird.

* Das SCM-Archiv kann nun in der Applikation A neu importiert werden, das alte Archiv wird gelöscht. Es enthielt zwar die Änderungen von 123 auf 125, die sich im neuen Archiv nicht finden, angenommenerweise ist diese Version 125 in A aber nicht pflegerelevant.

Dieses Szenario kann durchaus als typisch bezeichnet werden. Die meisten Änderungen werden kompatibel vorgenommen oder treffen nicht für alle Applikationen zu, wenn sorgsam in der Komponentenentwicklung gearbeitet wird.

Damit verschiebt sich allerdings die '''Sicht vom Primat des SCM-Archivs auf das Primat der Files'''. Zumindestens während des Überganges der Nutzung der neuen Hauptversion 137.

Wie sollte konkret umgegangen werden:

* Die neue Hauptversion 137 der Komponente wird aus dem erhaltenem SCM-Archiv auf einer unabhängigen Stelle im Filesystem als Workingtree exportiert. Die Files der Komponente in der Applikation werden nicht geändert.

* Nun erfolgt der Einzelfilevergleich zwischen dem neuen Workingtree und den bestehenden Files. Selbstverständlich sind dabei die Einträge im Log des SCM-Archives für das Verständnis der Änderungen wichtig. Letzlich werden aber die Inhalte der Files auf Passfähigkeit begutachtet.

* Im zweiten Schritt werden die neuen Files als File, nicht über das SCM-Archiv in die bisherige Applikation kopiert und die im alten aber nicht im neuen Archiv befindliche Files werden gelöscht. Letzteres ist wesentlich und typisch wenn in der Komponente umstrukturiert wurde. Das bisherige Archiv, im Beispiel auf der 125 stehend, wird erstmal weiterverwendet. Der neue Stand wird also als 126 committet.

* Danach erfolgt der Test von A.

* Im Idealfall passt alles. Es gibt keine Änderungen. Etwas weniger ideal aber erwartbar ist, dass der Stand der Komponente 137 vollständig akzeptierbar ist, allerdings sind kleine Nachbesserungen in der Applikation notwendig.

* In diesen beiden Fällen kann dann das Archiv ausgetauscht werden. Das alte SCM-Archiv mit den Versionsständen 123, 125 und zuletzt 126 wird entfernt, statt dessen das gelieferte Archiv mit der 137 eingesetzt. Im Archiv kann dann nachgelesen werden, welche Änderungen es insgesamt in der Komponente gab, auch wenn sich diese nicht aus der Applikation A ergeben hatten. Möglicherweise sind diese Änderungen für die Weiterentwicklung von A interessant oder wichtig.

Der Fall der notwendigen Nachbesserung in der Komponente, weil die Funktionalität in A nicht passt, erfordert den oben beispielhaft dargestellten Zyklus der Nachbesserung in der Komponente mit notwendigem Aufwand wiederum für alle Applikationen. Entweder dieser Aufwand ist gerechtfertigt oder möglich. Oder nach entsprechenden Klärungen ordnet sich die Applikation A dem gegebenen Stand der Komponente unter, oder mindestens vorerst wird weiter mit der eigenen Variante A gefahren.

* Konkret kann dabei auf der neu gelieferten Version 137 mit neuem Archiv aufgesetzt werden: Dort werden die notwendigen Änderungen vorgenommen und das ganze wird als neuer Versionsstand 138 aus Sicht der Applikation A an die zentrale Komponentenentwicklung zurückgeliefert.

* Der Zyklus beginnt damit erneut, hoffentlich mit kleinen und kompatibel ausführbaren Änderungen, die für eine Beruhigung der Zyklen sorgt.

===Überblick über die Anzahl Archive für die selbe Softwarekomponente ?===

Die Kapitelüberschrift ist mit einem Fragezeichen versehen.

Angenommen, es gibt etwa 10+x Stellen, an denen die selbe Softwarekomponente eingesetzt wird. Das kann sich auf mehrere PCs und Bearbeiter verteilen, auch auf dem selben PC mag es mehrere Stellen geben, weil die Softwarekomponente eben in verschiedenen Applikationen drinsteckt.

Bazaar sieht nun vor, an jedem Working tree ein eigenes Archiv zu haben. Man kann mit Bazaar-Bordmitteln dann pushen, pullen, mergen jeweils mit einem anderen Archiv. Insbesondere kann an jedem Archiv auch ein 'submit-branch'' angegeben werden (Settings - configuration - branch). Damit kann unaufwändig ein etwas zentraleres Archiv angesprochen und beobachtet werden.

Dennoch, bei 10+x Archiven, die sich gut gegeneinander updaten lassen, können sich Unterschiede breitmachen und Merge-Aufwand erzeugen, die überhaupt nicht gewünscht sind. Außerdem kann man leicht den Überblick verlieren, wo denn überhaupt welche Bearbeitung stattgefunden hat. Beim Mergen muss man dann erst einmal überlegen, was denn die bessere Version ist. Damit artet das Ganze in Arbeit aus, die man doch vermeiden und verbessern wollte ....

Die Arbeit mit einem zentralen Archiv gestaltet sich dann einfacher, wenn das es eigentlich nur einen Hauptzweig gibt und Unterschiede vermieden werden sollen. Unterschiede entstehen eigentlich eher unerwünscht bei Parallelarbeiten und sind möglichst schnell wieder abzustellen.

Es soll hier aber nicht den zentralen Archiven das Wort geredet werden. Der Vorteil der dezentralen Archive ist gerade ein gewisses unabhängiges Arbeiten und eine gute Merge-Unterstützung. Jedoch - total denzentral kann auch zuviel des Guten sein.

Zweckdienlich kann es sein, für einen Bearbeiter auf einem PC nur ein Archiv zu halten. Voraussetzung dafür ist aber, das alle Applikationen tatsächlich immer mit den gleichen Source-Versionsstand compiliert werden sollen. Ich habe auf einem PC auch nur eine Entwicklungsumgebung (Eclipse für Java), in der alle Quellen für alle Projekte eingebunden sind. Damit ist es bei Strukturänderungen relativ einfach, die automatischen Möglichkeiten des Tools zu nutzen (renaming, wird automatisch in allen sichtbaren Quellen nachgezogen). Außerdem gewinnt man bei möglicherweise problematisch inkompatiblen Änderungen sofort den Überblick, wo es klemmen könnte. Es wird jeweils alles compiliert. Diese Arbeitsweise hat sich bewährt.

Dennoch, für die einzelnen Applikationen gibt es bei mir verschiedene Stellen im Filesystem (Working area). Wichtig ist, dass eine Änderung eben gerade ausgeführt mit Auswirkungen auf Applikation X zwar formell compilierfähig ist aber damit noch nicht getestet, sich nicht sofort auf einen Auslieferungsstand mit Feinkorrektur auswirkt. An diesen Stellen compiliere ich mit einem Batch-Aufruf. Das ist einfacher. Beim Batch-Aufruf werden die Files in der Working-Area benutzt. Bei einer Feinkorrektur braucht es keinen entwicklungsumgebungsunterstützten Test mit Schritt-Debugging usw. Die Korrektur wird textuell ausgeführt, compiliert und zur Laufzeit getestet.

Ein Gesamttest wird aber in dem zentralem Eclipse-Projekt mit zentralisierten Files. Damit wird immer auf dem letzten Stand basierend getestet. Von dieser zentralisierter Working-Area wird dann das Archiv (Bazaar) gepflegt, von dort wird committed.

Wie kommt aber nun eine Detailänderung aus einer denzentralen Workingarea in das Archiv? Wie kommt der letzte Archivstand in die dezentrale Working-Area?

Für die zweite Frage gäbe es eine Antwort:

bzr export %DST% --per-file-timestamps -r %REVISION%

Damit werden nur Files nach %DST% kopiert, sogar mit dem originalem Datum (geht nicht bei Unix), optional mit einer angegebenen Revisionskennzeichnung. Aber: Das ist ein blindes kopieren. Man sieht nicht vorher, welche Änderungen sich damit ergeben. Man übersieht und überschreibt für immer Änderungen in der Workingarea. "bzr export" eignet sich für die Erstellung einer neuen workingarea ohne Archivanbindung, nicht aber für's updaten.

Die ggf. bessere Variante liegt außerhalb des SCM, nämlich bei den altbewährten '''File-Baum-Diff-Tools'''. Da gibt es eine Menge, jeder hat seine gewohnten Tools, diese haben sich bewährt. Man kann die Unterschiede per File-Vergleich sichten und damit übersichtlich entscheiden, ob eine Änderung denn überhaupt wesentlich ist, was eine andere Änderung an Nebeneffekten bewirken könnte usw. usf. Ein Merge mit bazaar ist zwar auch ganz gut, aber es erzeugt zuerst Seitenversionen, bei denen man im Nachhinein (!) dann feststellt, dass das eigentlich unerwünschte oder unnötige Seitenzweigänderungen sind. Damit sind diese aber schon im Archiv manifestiert, haben Datenmüll erzeugt und müssen dann zusätzlich im Nachhinein wieder ausgebessert werden (Anschauen, löschen von *.THIS, *.BASE und *.OTher). Die Arbeit kann man sich sparen.

Die Lösung wäre also hier: Ein Archiv (pro PC) mit dem Haupt-Workingtree aus Haupt-Workingarea, '''manuelles Abstimmen von Files in den einzelnen Workingareas''' für die jeweiligen Applikationen. Man kann in diesem Zusammenhang "bzr export" nutzen um letzlich genau den Archivstand in eine Applikations-Workingarea hineinzulegen. Zuvor sollte die Workingarea gelöscht bzw. besser parallel gesichert und danach gelöscht werden. Erfolgt das löschen nicht, dann besteht die Gefahr, dass in der Applkations-Workingarea Files liegen, die wichtig für die Applikation sind, sich aber nicht im SCM-Archiv befinden. Das sollte unbedingt kontrolliert und vermieden werden. Wird zuerst per "move"- Befehl gelöscht und gesichert, danach die Files per "bzr export" neu eingespielt und danach compiliert, dann fallen diese Fehler auf. Bei Problemen kann man auf die gesichrten Files zurückgreifen. Letztlich sollte die Sicherung aber vernichtet werden, da sie sonst auch wieder nur Datenmüll ist.

Es gibt noch eine andere Möglichkeit des Bindens nur eines Archives an mehrere Working-Areas:

Unter Linux kann ein symbolischer Link <code>bzr.</code> auf das Archiv gelegt werden. Das Archiv muss dabei auf demselben Datenträger stehen, einige Funktionalitäten in Bazaar gehen sonst nicht. Aber es kann zentral irgendwo anders stehen. Mehrere symbolische Links können auf das selbe Archiv zeigen.

Nun kann man damit
* ''commit'' von verschiedenen Working-Areas ausführen und trifft jeweils das selbe Archiv. Die committeten Files erscheinen damit im Archiv, nicht jedoch automatisch in den anderen Working-Areas!
* den Filebaum betrachten und feststellen, welche Änderungen im Archiv passiert sind, die nicht aus dieser Workingarea stammmen. Man kann sich über die Bazaar-GUI die Differenzen anzeigen. Da Bazaar diese Arbeitsweise so nicht vorsieht, präsentieren sich die Änderungen spielelverkehrt. Geänderte Files mit neuem Stand im Archiv erscheinen als ''commitwürdig'' der alten Files. Neue Files im Archiv erscheinen als ''deleted files''. Um hier zu unterscheiden, was denn Änderungen in der speziellen Working Area sind, muss man schon die eigenen Files kennen. Dabei hilft ein kleines Backup des letzten Standes aus dem SCM, auf dem aufgesetzt worden ist, dabei wieder mit File-Diff-View außerhalb des SCM - nur um die eigenen Änderungen zu erkennen. Das ist damit eindeutig. File-Diff-Tools können teils auch direkt in Zip-Archiven arbeiten. Man benötigt also nur ein einfaches Zip-Backup angelegt bevor man in der speziellen Working area losarbeitet. Man kann auch postum über ein "bzr export" den Ausgangstand wieder erzeugen.
* committen einzelner Files, die nur in dieser Working Area geändert worden sind.
* Zuletzt über

bzr revert

*+den Stand aus dem SCM-Archiv in die working-Area hinein synchronisieren um wieder einen gemeinsamen Ausgangsstand zu haben.

Unter Windows geht das mit dem symbolischen Link nicht. Man kann aber stattdessen mit einem move-Befehl das Archiv von einem Platz auf einen anderen Hin- und Herschieben. Es sollte zuletzt immer auf dem zentralen Platz wieder landen, sonst weiß man nicht wo es aktuell steht. Der <code>move</code>-Befehl kopiert nicht die Archiv-Files auf der Festplatte sondern ändert tatsächlich nur einen Verzeichniseintrag. Das ist also von der Belastung der Festplatte und vom Zeitaufwand her gesehen sehr billig. Vorraussetzung: Selbe Partition der Festplatte!

Ich habe dazu folgende Befehlsfolge in einem zentralen Batch-File niederlegt:

File <code>bzr_mvExpl.bat</code>

set CMPN=%1
REM Add the Bzr directory to system-wide PATH environment variable
SET PATH=D:\Progs\Bazaar;%PATH%
attrib -h \Bzr\%CMPN%\.bzr
if not exist .bzr move \Bzr\%CMPN%\.bzr .bzr
echo Bazaar-Explorer:
bzrw.exe explorer .
bzr.exe version-info >_bzr_version.txt
if not exist \Bzr\%CMPN%\.bzr move .bzr \Bzr\%CMPN%
attrib +h \Bzr\%CMPN%\.bzr

Wichtig für das funktionieren des move-Befehls ist das Rücksetzen des Hidden-Attributes für das .bzr-Archiv.

Dieses File wird in einem File im Arbeitsverzeichnis (Working Area)

.bzr.bat

mit drei Zeilen

SET USERNAME=hartmut
SET BZREMAIL=hartmut.schorrig@vishia.de
bzr_mvExpl.bat srcJava_vishiaBase

aufgerufen. Das <code>srcJava_vishiaBase</code> ist hierbei der Name der Softwarekomponente und der Name des Verzeichnisses in dem das <code>.bzr</code>-Archiv steht. Alle <code>.bzr</code>-Archive stehen dabei zentral auf der selben Festplatte (keine Laufwerksangabe am Pfad) im Verzeichnis <code>\Bzr</code>. Da dies so zentral festgelegt ist, kann das Batchfile direkt darauf zugreifen. Im Start-Batchfile sind zusätzlich in lokal gültigen Umgebugsvariablen die Commit-Daten niedergelegt. Diese sind damit Working-Area-spezifisch.

Es gibt dann noch einen weiteren interessanten Batchfile:

File <code>bzre.bat</code>

@echo off
REM Add the Bzr directory to system-wide PATH environment variable
SET PATH=D:\Progs\Bazaar;%PATH%
SET USERNAME=hartmut
SET BZREMAIL=hartmut.schorrig@vishia.de
::
if not "%1" == "cd" goto :nocd
echo on
cd %2
echo off
:nocd
REM if the directory contains .bzr.bat, it is processed. It doesnt return!
REM if the directory or any parent does not contain .bzr change to the parent.
if exist .bzr.bat .bzr.bat
if not exist .bzr cd ..
if exist .bzr.bat .bzr.bat
if not exist .bzr cd ..
if exist .bzr.bat .bzr.bat
if not exist .bzr cd ..
if exist .bzr.bat .bzr.bat
echo Bazaar-Explorer: %CD%
bzrw.exe explorer .
bzr.exe version-info >_bzr_version.txt
goto :ende

:ende
exit /B

Dieses File kann entweder parameterlos gerufen werden oder mit den Parametern

bzre.bat cd aktuelles_Verzeichnis

Anhängig davon ob im angegebenen aktuellen Verzeichnis oder mehreren übergeordneten Verzeichnissen entweder ein Verzeichnis <code>.bzr</code> vorgefunden wird - das wäre also ein lokales eigenes Archiv - oder es wird ein File <code>.bzr.bat</code> vorgefunden, wird entweder der Bazaar-Explorer mit dem vorhandenen lokalen Archiv gerufen, oder es wird das oben aufgeführte <code>bzr_mvExpl.bat</code> aufgerufen, das das Archiv hin-und herkopiert. Man hat also einen Aufruf für alle vorkommenden Fälle und kann den Bazaar-Explorer unabhängig und schnell starten, ohne nachdenken und suchen zu müssen.

====Synchronisierung mehrerer Bearbeiter====

Wenn jeder sein eigenes bzr-Archiv hat und es wird gemerged, dann ist das so wie es Bazaar vorsieht.

Wenn es aber einen Hauptbearbeiter gibt und mehrere eher Nutzer dieser Sources, dann kann es auch eine File-diff-Tool-Abstimmung geben wie oben dargestellt. Man muss sich nur ab und zu in einem Netzwerk treffen. Es will nicht jeder immer und überall alle Files ändern.

==Source Content Management oder hart archivieren? Nur Quellen im SCM?==

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.

===Quellen und Generate in einem Verzeichnis ?===

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.

===Archivierung der Datenbasis des SCM===

Die Datenbasis besteht aus Files, die in üblicher Art als File-Bündel archiviert und restauriert werden können.

==Mehrere Produkte aus einem Repository==
@ident=SCM-Cmpn-de

Das große Thema ist Wiederverwendung (Reuse). Häufig zu Beobachten: Reuse besteht aus copy'n paste and change. Die Quellen wandern also irgendwo anders hin, bzgl SCM auch für den einzelnen besser zu beherrschen - man muss sich nur mit dem beschäftigen, was man selbst hat.

Das ist keine wirkliche Wiederverwendung. Der wirkliche Vorteil des reuse geht dabei verloren:
* Fehler, die in Produkten festgestellt werden, werden in den jeweiligen Modulen korrigiert und sind dann automatisch auch für andere Produkte mit korrigiert, obwohl sie dort ggf. noch gar nicht aufgefallen sind.

Für true-reuse ist es notwendig, die Software-Module so zu bauen, dass sie '''unverändert''' in verschiedenen Produkten verwendbar sind und das Änderungen für alle Produkte nutzbar sind. Das ist eine Frage der Schnittstellen. Die Schnittstellen sind viel wichtiger als die innere Funktionalität. Letztere kann man immer noch verbessern. Schnittstellenänderungen sind kritisch. - Andererseits sind Schnittstellenänderungen auch verträglich, wenn sie formell adaptiert werden können.

Ein shared-Repository in bazaar scheint die Lösung zu bieten, aus einem recht großen Quellenumfang für verschiedene Komponenten verschiedene Quellen herauslösen zu können. Die Komponenten haben selbe gemeinsame Quellen, ggf. in verschiedenen Revisionen, die aber immer abgeglichen werden können sollten. Die Komponenten sind dann Basis für ein Produkt. Komponenten existieren in Form von libs oder jars in Java und können eigenständig getestet werden:

Quellen Komponenten Produkte
viele ===> weniger ===> aus Komponenten
verschiedene überschaubar und Produkt-spezial-Quellen
gebaut.

Wie funktioniert shared-Repository als zentraler Bezug - bin beim testen. (Hartmut)
==Zentrale Ablage für Repositories==
@ident=SCM-centralRepos-de

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.

===Creating one shared repository in the local space===
The ''local space'' means any external hard disk, network folder or such which is owned by one person, by me. It is my local space, which can be used from some more people in my direct environment.

For any component of sources one shared repository should be created one time. On one sub directory per component: ''bzre: Bazaar -> Start -> Initialize: (x) Shared repository''. An existing plain branch can be pushed to them.

===Creating a branch for working===

* Create a new plain branch at the working position: ''bzre: Bazaar -> Start -> Initialize: (x) Plain branch''.
* Pull from a shared repositiory: ''Button Pull, select the shared repository, select a branch.
** If there are some files already, create the branch at a new position and then move .bzr subdir.

==Branches und dessen Auflösung==
@ident=SCM-sidebranch-en

;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.

Source-Version-Management-de

JcHartmut — Wed, 07 Nov 2012 21:43:13 GMT

JcHartmut: Source Content Management oder hart archivieren? - Verzeichnissstuktur-Rückschluss

==Source code management (SCM)==
@ident=SCM

Links:
* [[Bazaar-guide]]: a guide to use Bazaar.

This size is in german, because it is discussed in a german team. It will be presented in english in the future. TODO

==Kurzer Abriss, Arbeit mit MKSSI, git, mercurial, Bazaar==
@ident=SCM-gitCo

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 [[https://bitbucket.org/jchartmut/cruntimejavalike 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.

==Einzelne Files vs. SCM-Archiv==
@ident=SCM-Files
.
===Primat der Datenhaltung im SCM===

Ein Source Content Management (SCM) wie Bazaar, git oder andere enthält alle relevanten Files einschließlich deren Versionierung in einer eigenen internen Form (Datenbasis) gespeichert. Dem gegenüber steht der ''Working tree''. Das sind die Files mit denen man arbeitet. Der ''working tree'' lässt sich jederzeit aus dem SCM für beliebige Versionen rekonstruieren. Committet man immer auch Änderungen, dann ist der ''working tree'' temporär. Man braucht ihn nur während des Editierens, Compilierens, Makens. Danach kann er ersatzlos gelöscht werden, da alles im Archiv des SCM steht.

Damit steht das SCM im Mittelpunkt. Das ist auch in Ordnung so, da dies die entscheidende Stelle für die Versionierung der Sources ist. Diesbezüglich unterscheiden sich zentrale SCM nicht von den verteilten. Lediglich - bei einem zentralem SCM braucht man die Serveranbindung.

Die Files stehen meist als ''working tree'' solange bereit, bis man sie nach vorigem ''commit'' oder ''checkin'' löscht. Damit kann man auch bei einem zentralem SCM dezentral an den Files arbeiten, wenn auch nicht einchecken oder ältere Versionen sichten.

Die Alternative, ein File-Baum nur in direkter Verbindung mit dem SCM bereitzustellen gibt es auch. Dann sind die Files nur aufrufbar, wenn das SCM läuft. Die Files werden vom Betriebssystem dann nicht auf der Festplatte mit dem üblichen Filesystem gespeichert sondern alle Filezugriffe des Betriebssystems laufen über den SCM-Treiber. Damit sind keine Files vorhanden wenn das SCM mit seinem Archiv nicht zugänglich ist. Diese Variante ist die konsequenteste Anbindung an ein SCM, aber für eine offline-Arbeit eher schwierig und daher weniger verbreitet.

Es gibt also ein '''Primat des SCM gegenüber den Einzelfiles''', das mehr oder weniger stark ist.

===Gegenentwurf - Primat der Einzelfiles, lediglich Ablage und Austausch über das SCM===

Es ist möglich, die Hauptsicht auf die Files zu legen und das SCM nur als ''Ablage'' oder Austauschmedium zu nutzen. Die Files werden dann immer beibehalten, in das SCM wird nur eingecheckt oder committet. Das SCM hat dann den Zweck, auf Altversionen rückgreifen zu können und Versionen einfach zu vergleichen. Austauschen wird man gegebenenfalls über das SCM nur bestimmte Schnittstellenfiles, wenn die Bearbeitung sonst in einer Hand liegt.

Diese Arbeitsweise hat einen entscheidenden Nachteil: Es wird gegebenenfalls nicht bemerkt, dass wichtige Files überhaupt nicht in das SCM aufgenommen worden sind. Wenn dann keine weitere Datensicherung besteht und nur noch der Datengehalt des SCM verfügbar ist, sei es wegen einem Hardwarecrash, sei es bei Bearbeiterwechsel usw, dann kommt das Böse Erwachen. Es compiliert nicht, was fehlt...

Der andere Nachteil ist, das sich möglicherweise Alt-Files ansammeln, man löscht diese nicht aus Befürchtung, irgendwo könnten diese noch wichtig sein.

Tendiert ein Bearbeiter zu der Arbeitsweise, eher Files zu behalten und nur einzuchecken, dann muss es einen Test an anderer Stelle auf Vollständigkeit der Daten im SCM geben. Am einfachsten ist dies getan, wenn auf einem leerem PC oder Verzeichnisbaum aus dem SCM ausgecheckt wird und dort alle relevanten Makeprozesse durchlaufen werden. Laufen diese fehlerfrei und ist das Ergebnis korrekt, dann sind die Sources vollständig.

===Kompromiss - Arbeit mit Files und dem SCM===

Eine kleine Anekdote:

Seit mehr als einem Jahrzehnt läuft Software auf Anlagen. Sorry, die Welt ist nicht so schnellebig wie junge Leute heute glauben. Die Software wurde zu einer Zeit erstellt (seit 1994), zu der SCM noch nicht so gängige Praxis war. Jedoch wurde die Software in fleißiger Arbeit postum eingecheckt, prozess-konform, wie es sich ordentlich gehört. - Ein paar Jahre später, Nachbesserung von Hardware auf der Anlage, gegebenenfalls ist die Software betroffen. Mittlerweile war das SCM die "alte Version", doch selbstverständlich, man hat ja Zugänge und Archive gespeichert. 1 Tag Arbeit, und der Zugang funktioniert. Nun jedoch zeigte es sich, das zwar damals alles ordentlich eingecheckt wurde, aber nur die offensichtlichen Endstände. Da fehlte etwas, da stimmt was nicht - da war doch noch was ????. Bis ein Kollege damit herausrückte, er hat mal alle Stände auf CD direkt archiviert, die CD liegt im Schrank.

Die Files auf der CD hatten dann tatsächlich für mich als Entwickler einen hohen Wiedererkennungswert, wichtig dabei die Verzeichnisstruktur. Da die Backups von den laufenden Arbeitsstadionen gezogen worden sind, direkt ohne Zusatzaufwand als Filebaum, war eine Vollständigkeit gewährleistet. Die Zusatzarbeit des Eincheckens in das damalige SCM versionsgetreu hatte also Informationen verwässert.

Mit Diff-View auf den Files war dann schnell wieder der Überblick über den Gang der Entwicklung da. Übrigens - wenn man alles sehr fein säuberlich dokumentiert, auf 100 Seiten oder mehr, muss man dann später die 134 Seiten wieder lesen - ist auch Aufwand.

==>Über lange Jahre ist zwar ein SCM-System stabil und kritikunwürdig (ja klar), aber die Arbeit damit nicht. Zum Glück hat man dann backups der Files direkt.

==>Ein SCM ist wichtig für die zeitnahe Arbeit. Insbesondere für das Diff-View und die Nachverfolgung, wann wurde was geändert. Ohne SCM ist nicht!!! Aber die Arbeit direkt mit den Files hat auch seine Vorteile.

===Mehrere Arbeitsverzeichnisse, mehrere SCM-Archive, Wiederverwendung===

Wird Software stark wiederverwendet, dann erscheinen die gleichen Quellfiles möglicherweise innerhalb der jeweiligen Applikationen selbst beim selben Bearbeiter mehrfach.

Diese konsequente Art der Wiederverwendung ist nicht häufig anzutreffen. Wiederverwendung wird meist verstanden als ''kopiere es und pass es an''. Die konsequente Wiederverwendung - gleiche Quellen ohne Anpassung - hat den Vorteil dass Fehler oder Verbesserungen in einer Anwendung gefunden sofort auch in den anderen Anwendungen nützen. Allerdings muss man bei diesen wiederverwendeten Quellen die Unabhängigkeit von der jeweiligen Applikation beachten. Eigentlich eine konsequente Softwaretechnologie.

Werden die Quellen mehrfach für verschiedene Applikationen benutzt, dann kann nicht vorausgesetzt werden, dass alle Projekte mit einem einheitlichen Stand der Quellen arbeiten. Wünschenswert ist es zwar, dass an allen Stellen mit der selben Version gearbeitet wird, eben wegen der Vorteile. Andererseits kann aber eine Änderung in einer Applikation zwar allgemeingültig erfolgen, jedoch nicht fehlerfrei und allgemeingültig genug. In einer anderen Applikation können sich Folgefehler ergeben, die erst gefunden und getestet werden müssen. Ergebnis dessen ist zwar eine verbesserte Allgemeingültigkeit, jedoch ist dies mit Arbeit verbunden. Für Bugfixes aus Sicht einer Anwendung werden sich daher Differenzen nicht vermeiden lassen.

Damit sind möglicherweise Seitenzweige im Archiv des SCM erforderlich. Andererseits sollte ein Zuviel an Seitenzweigen vermieden werden, besser ist es jeweils nach Korrekturen den Hauptzweig anzuwenden. Die Seitenzweige sollten eher temporärer Natur sein.

Das SCM Bazaar unterstützt Seitenzweige mit automatisch unterstütztem merge.

Um allerdings Seitenzweige zu vermeiden, kann sich folgende Vorgehensweise als geeignet erweisen:

* Angenommen, eine Applikation A verwendet die Hauptversion 123.

* In einer anderen Applikation B werden in einer gemeinsamen Source-Komponente Verbesserungen vorgenommen. Damit entsteht letzlich die Hauptverson 137.

* Nun wird versucht, die Hauptversion 137 auch in A anzuwenden. Angenommen, es gibt Anpassungsnotwendigkeiten, die sich erst aus Sicht der Applikation A zeigen aber insgesamt die gemeinsame Komponente aufwerten. Es entsteht Hauptversion 139.

* Nun sollte diese Hauptversion auch für B anwendbar sein. Hat man Schnittstellen gut definiert, dann sollte es nicht unbedingt schon wieder Komplikationen geben. Es bleibt also bei der 139.

* Das Ganze soll nun auch für weitere Applikationen passen. Eventuell sind wiederum Anpassarbeiten notwendig.

Werden die Anpassungen nicht nacheinander sondern parallel ausgeführt, von verschiedenen Bearbeitern, dann entstehen zwischendurch Seitenzweige, die jeweils wieder bereinigt werden müssen. Diese Bereinigungen sind teils mergen, teils Schnittstellen klarer formulieren, teils Verbesserungen für allgemeingültige Verwendung. Es ist nun günstig, diese Bereinigungen in einer Referenzapplikation zentralisiert auszuführen. Der Test, ob die Ergebnisse bei den einzelnen Applikationen passt, ist dann wieder dezentralisiert.

Verwendet man Bazaar, dann entstehen dezentralisiert divergierende Versionen. Diese in einem Baum zusammenzufassen kann sich gegebenenfalls als nicht zweckmäßig erweisen. Gegebenenfalls ist es besser, in der zentralisierten Bearbeitung der Komponente mit der Referenzapplikation zwar alle Inputs zu verwerten, aber nicht auch alle nuancierte Änderungen im Original zu berücksichtigen. Oft ist ein Austausch - eine kompatible aber bessere Variante - die einfache Lösung, die auch Zufriedenheit bei den einzelnen Applikationen auslöst.

Damit ergibt sich allerdings die Situation, dass das formelle Arbeiten mit den Bazaar-Archiven nicht funktioniert. Denn:

* Applikation A hat ihre Version 125 abgegeben (merge-Input), die eine Verbesserung der zuvor erhaltenen (poll) Version 123 darstellt.

* Applikation B hat aber in ihrer Version 137 aus der gemeinsamen Versionen 123 hervorgegangen möglicherweise adäquate aber nicht gleiche Lösungen gefunden, die auch der Verbesserung in A entsprechen.

* Die zentralisierte Bereinigung entschließt sich daher, zwar die Funktionalität von A in 125 in der Nachbearbeitung zu garantieren, enthält aber nicht formell den Versionsstand 125 von A. Die nachbearbeitete Komponente wird also als Version 137 wieder der Applikation A angeboten, jedoch nicht passend in Archivbaum, der in A verwendet wird.

* A muss nun einerseits möglichst positiv entscheiden, dass die Änderungen zu Version 137 überhaupt benutzt werden. Die positive Entscheidung bedeutet die Fortsetzung der Partizipation an der Weiterentwicklung in der Zukunft. Andererseits muss A den Aufwand treiben, zu testen, dass es keine negativen Auswirkungen gibt.

* Formell kann die Applikation A nicht das bisherige SCM-Archiv einfach updaten, da die eigene letzte Version nicht enthalten ist.

* Zielführender ist es, nun auf der Basis der Sichtung der Differenzen der Files zu entscheiden, welche Tests ausgeführt werden müssen und welche Auswirkungen zu erwarten sind. Möglicherweise findet sich die Funktionalität der ursprünglichen Verbesserung 125 in A in nur in wenigen Zeilen nicht identisch aber passend ausgeführt. Alle anderen Änderungen sind nicht relevant da sie nicht verwendete Funktionen betreffen. Es ist also auf Basis der File-Differenz-Sichtung leicht zu entscheiden, dass nunmehr auf der neuen Version 137 aufgesetzt wird.

* Das SCM-Archiv kann nun in der Applikation A neu importiert werden, das alte Archiv wird gelöscht. Es enthielt zwar die Änderungen von 123 auf 125, die sich im neuen Archiv nicht finden, angenommenerweise ist diese Version 125 in A aber nicht pflegerelevant.

Dieses Szenario kann durchaus als typisch bezeichnet werden. Die meisten Änderungen werden kompatibel vorgenommen oder treffen nicht für alle Applikationen zu, wenn sorgsam in der Komponentenentwicklung gearbeitet wird.

Damit verschiebt sich allerdings die '''Sicht vom Primat des SCM-Archivs auf das Primat der Files'''. Zumindestens während des Überganges der Nutzung der neuen Hauptversion 137.

Wie sollte konkret umgegangen werden:

* Die neue Hauptversion 137 der Komponente wird aus dem erhaltenem SCM-Archiv auf einer unabhängigen Stelle im Filesystem als Workingtree exportiert. Die Files der Komponente in der Applikation werden nicht geändert.

* Nun erfolgt der Einzelfilevergleich zwischen dem neuen Workingtree und den bestehenden Files. Selbstverständlich sind dabei die Einträge im Log des SCM-Archives für das Verständnis der Änderungen wichtig. Letzlich werden aber die Inhalte der Files auf Passfähigkeit begutachtet.

* Im zweiten Schritt werden die neuen Files als File, nicht über das SCM-Archiv in die bisherige Applikation kopiert und die im alten aber nicht im neuen Archiv befindliche Files werden gelöscht. Letzteres ist wesentlich und typisch wenn in der Komponente umstrukturiert wurde. Das bisherige Archiv, im Beispiel auf der 125 stehend, wird erstmal weiterverwendet. Der neue Stand wird also als 126 committet.

* Danach erfolgt der Test von A.

* Im Idealfall passt alles. Es gibt keine Änderungen. Etwas weniger ideal aber erwartbar ist, dass der Stand der Komponente 137 vollständig akzeptierbar ist, allerdings sind kleine Nachbesserungen in der Applikation notwendig.

* In diesen beiden Fällen kann dann das Archiv ausgetauscht werden. Das alte SCM-Archiv mit den Versionsständen 123, 125 und zuletzt 126 wird entfernt, statt dessen das gelieferte Archiv mit der 137 eingesetzt. Im Archiv kann dann nachgelesen werden, welche Änderungen es insgesamt in der Komponente gab, auch wenn sich diese nicht aus der Applikation A ergeben hatten. Möglicherweise sind diese Änderungen für die Weiterentwicklung von A interessant oder wichtig.

Der Fall der notwendigen Nachbesserung in der Komponente, weil die Funktionalität in A nicht passt, erfordert den oben beispielhaft dargestellten Zyklus der Nachbesserung in der Komponente mit notwendigem Aufwand wiederum für alle Applikationen. Entweder dieser Aufwand ist gerechtfertigt oder möglich. Oder nach entsprechenden Klärungen ordnet sich die Applikation A dem gegebenen Stand der Komponente unter, oder mindestens vorerst wird weiter mit der eigenen Variante A gefahren.

* Konkret kann dabei auf der neu gelieferten Version 137 mit neuem Archiv aufgesetzt werden: Dort werden die notwendigen Änderungen vorgenommen und das ganze wird als neuer Versionsstand 138 aus Sicht der Applikation A an die zentrale Komponentenentwicklung zurückgeliefert.

* Der Zyklus beginnt damit erneut, hoffentlich mit kleinen und kompatibel ausführbaren Änderungen, die für eine Beruhigung der Zyklen sorgt.

==Source Content Management oder hart archivieren? Nur Quellen im SCM?==

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.

===Quellen und Generate in einem Verzeichnis ?===

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.

===Archivierung der Datenbasis des SCM===

Die Datenbasis besteht aus Files, die in üblicher Art als File-Bündel archiviert und restauriert werden können.

==Mehrere Produkte aus einem Repository==
@ident=SCM-Cmpn-de

Das große Thema ist Wiederverwendung (Reuse). Häufig zu Beobachten: Reuse besteht aus copy'n paste and change. Die Quellen wandern also irgendwo anders hin, bzgl SCM auch für den einzelnen besser zu beherrschen - man muss sich nur mit dem beschäftigen, was man selbst hat.

Das ist keine wirkliche Wiederverwendung. Der wirkliche Vorteil des reuse geht dabei verloren:
* Fehler, die in Produkten festgestellt werden, werden in den jeweiligen Modulen korrigiert und sind dann automatisch auch für andere Produkte mit korrigiert, obwohl sie dort ggf. noch gar nicht aufgefallen sind.

Für true-reuse ist es notwendig, die Software-Module so zu bauen, dass sie '''unverändert''' in verschiedenen Produkten verwendbar sind und das Änderungen für alle Produkte nutzbar sind. Das ist eine Frage der Schnittstellen. Die Schnittstellen sind viel wichtiger als die innere Funktionalität. Letztere kann man immer noch verbessern. Schnittstellenänderungen sind kritisch. - Andererseits sind Schnittstellenänderungen auch verträglich, wenn sie formell adaptiert werden können.

Ein shared-Repository in bazaar scheint die Lösung zu bieten, aus einem recht großen Quellenumfang für verschiedene Komponenten verschiedene Quellen herauslösen zu können. Die Komponenten haben selbe gemeinsame Quellen, ggf. in verschiedenen Revisionen, die aber immer abgeglichen werden können sollten. Die Komponenten sind dann Basis für ein Produkt. Komponenten existieren in Form von libs oder jars in Java und können eigenständig getestet werden:

Quellen Komponenten Produkte
viele ===> weniger ===> aus Komponenten
verschiedene überschaubar und Produkt-spezial-Quellen
gebaut.

Wie funktioniert shared-Repository als zentraler Bezug - bin beim testen. (Hartmut)
==Zentrale Ablage für Repositories==
@ident=SCM-centralRepos-de

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.

===Creating one shared repository in the local space===
The ''local space'' means any external hard disk, network folder or such which is owned by one person, by me. It is my local space, which can be used from some more people in my direct environment.

For any component of sources one shared repository should be created one time. On one sub directory per component: ''bzre: Bazaar -> Start -> Initialize: (x) Shared repository''. An existing plain branch can be pushed to them.

===Creating a branch for working===

* Create a new plain branch at the working position: ''bzre: Bazaar -> Start -> Initialize: (x) Plain branch''.
* Pull from a shared repositiory: ''Button Pull, select the shared repository, select a branch.
** If there are some files already, create the branch at a new position and then move .bzr subdir.

==Branches und dessen Auflösung==
@ident=SCM-sidebranch-en

;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.

Source-Version-Management-de

JcHartmut — Wed, 07 Nov 2012 21:28:30 GMT

JcHartmut: Kompromiss - Arbeit mit Files und dem SCM

Source-Version-Management-en

JcHartmut — Sat, 26 May 2012 22:20:43 GMT

JcHartmut: Created page with '==Source code management (SCM)== @ident=SCM-en Links: * Bazaar-guide: a guide to use Bazaar. This size is the english version ==More as one Repository for one product== @…'

==Source code management (SCM)==
@ident=SCM-en

Links:
* [[Bazaar-guide]]: a guide to use Bazaar.

This size is the english version

==More as one Repository for one product==
@ident=SCM-Cmpn-en

;Products with more as one components.

:Products are build with more as one components. Any component should be independent from the concretely product, tested as 'component' and may be used in more as one product.

:Conclusion: Do not mix sources, separate it. Therefore any component needs its own bzr archive.

;Sources of components should be located in a subdirectory of the product source tree. It is helpfull to use sub-directories to keep tidiness.

:In linux the sub directory may be a symbolic link. It means, the sources are located anywhere other in the file tree really and they can be maintained outside of the products source tree. In windows a real copy is necessary. But note, that a tool can often gotten the sources from any pathes in the file tree. It is a problem of absolute pathes versus a local sandbox.

:Conclusion: The .bzr repositiory of a component should be located in a sub directory of the product source tree.

:The name of the sub directory should, but doesn't need be identical with the name of the component.

;Getting of source tree of a component, getting its bzr archive

To get the bzr repository for a component of a product, use a simple batch or script file inside the product file tree in that directory, where the components root directory should be stored.

srcJava_Zbnf/ ..... This is the components directory, where its srcJava_Zbnf/.bzr should be located.
getBzr_srcJava_Zbnf.bat ..... This is the batch file to get the bzr archive of the component.

The batch file contains the simple line:

bzrGetVersion srcJava_Zbnf 59

This line should be kept simple and independent of any operation system. Note, that the batchfile works under linux too, if it is set 'executable'. The batchfile calls another script, 'bzrGetVersion' and names the storing directory and the requested version.

The '''bzrGetVersion''' scriptfile should be located anywhere in the PATH of the computer. It is a thing of installation, not a thing of the designated sources of the concrete product. It contains - for windows - and should be adapted to the concretely conditions at the PC-installation:

@echo off
REM How to get a component's sources:
REM The sources are contained in an bzr archive.
REM The bzr archive is an distributed repository.
REM An archive can exist as a copy on several places,
REM for example at a external hard disk or in network or as a local copy in another drive.
::
REM This is the path to all archives for this computer, correct it if necessary:
set BZR_ARCHIVEPATH=D:/Bzr
::
REM The batch renames the current directory if it is existing yet:
if not exist %1 goto :noCurrent
if exist %1.old rmdir /S/Q %1.old
if exist %1.old goto :nodelOld
ren %1 %1.old
if exist %1 goto :noRename
:noCurrent
::
REM copy the bzr archive and resynchronize all members with the required revision
echo on
bzr checkout %BZR_ARCHIVEPATH%/%1 %1 -r %2
@echo off
if not exist %1 goto :noBzr
goto :ende
::
:noRename
echo can't rename %1 to %1.old. It may be used yet. Do it manually!
pause
goto :ende
::
:nodelOld
echo can't delete %1.old. It may be used yet. Do it manually!
pause
goto :ende
::
:noBzr
echo The bzr archive is not pulled. The version may be faulty or the source path of bzr does not exist.
echo See error messages above.
pause
:ende
exit /B

If you follow the command statements, you can see that an existing directory is kept, of found, but the directory of the component is get newly anytime. It assumes that all bzr archives are located in one directory in the file tree, which can be an external disk too or an network path. See 'BZR_ARCHIVEPATH'.

The content of the archive will be cloned with the 'bzr checkout' command. The files are resynchronzed therefore. An independent working with the files and the cloned archive is possible, if necessary. The working can be pushed to its parent later using 'bzr push', 'bzr merge' etc. But in most cases only the resynchronized version of files are need.

==Zentrale Ablage für Repositories==
@ident=SCM-centralRepos-de

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.

===Creating one shared repository in the local space===
The ''local space'' means any external hard disk, network folder or such which is owned by one person, by me. It is my local space, which can be used from some more people in my direct environment.

For any component of sources one shared repository should be created one time. On one sub directory per component: ''bzre: Bazaar -> Start -> Initialize: (x) Shared repository''. An existing plain branch can be pushed to them.

===Creating a branch for working===

* Create a new plain branch at the working position: ''bzre: Bazaar -> Start -> Initialize: (x) Plain branch''.
* Pull from a shared repositiory: ''Button Pull, select the shared repository, select a branch.
** If there are some files already, create the branch at a new position and then move .bzr subdir.

==Branches und dessen Auflösung==
@ident=SCM-sidebranch-en

;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.

===Side branches===
less experience

bzr checkout ../masterlocation . -r REVNR

Gets a part of trunk untio REVNR. It is similar

bzr revert -r REVNR

What is the difference???

bzr update ../masterlocation .

This copies all files in the current dir. It seems to destroy the older-revision side branch (?)

Is there a possibility to checkin changes based on a older revision, without any merge. Only the changed files based on the older revision should be stored in the bazaar repositiory - to compare with other versions or look for changes later. Background: Changing of some source files to bugfix an older software. The reason is not develop and merge.

The workflow of develop and bugfix in a decentralized team is explained in
* [[http://doc.bazaar.canonical.com/latest/en/user-guide/organizing_branches.html doc.bazaar.canonical.com/latest/en/user-guide/organizing_branches]].

But this is not the problem of side branches, more the problem of development in team.

'''An side glance to git''':

$ git branch bugfix

creates a branch named 'bugfix' in the same only one repository. It is a branch with the same revision as the current one.

$ git checkout bugfix
now switches to the named branch.

$ git reset -q COMMITNR

This moves the current revision of the current branch (it is 'bugfix' to a older revision. COMMITNR is the hash number of any commit, see git log

$ git checkout .

resynchronized all files of the selected revision.

...changing any files and

$ git commit

builds a side branch in the repository (archive).

Now a switch to another branch and its revision is possible in the same sandbox to work with it:

$ git checkout master

now switches back to this named branch and resynchronizes all files. Work with it, commit etc.

If there should be worked only at one side branch to any time, and be worked at another side branch to another time, then only one sandbox is necessary. You can switch between the branches. The files are changed, all files are stored in the git archive.

If there should be worked with more as one side branches to the same time, a copy of the git archive is necessary. The archive and the files should be stored at different places on the hard disk, or at more as one computer etc. It isn't recommended to use the same git archive, may be with an symbolic link in linux. The disadvantage is: The git archive knows the current branch, which was selected with 'checkout'. If you want to use only one archive but more as one sandbox for the files, you can have a symbolic link in the sandboxes to the same archive. But then you have to switch between the side-branches before any status, commit etc. action are done in one of the sandboxes. But be attentive to your files. You may overwrite they if you are careless. You can't do that at the same time, maybe more as one people in network. It will be confused if they are work concurrently.

I haven't test yet, but it shouldn't a problem to merge the more as one git archives without conflicts, if only one archive has changed only one side branch.

[[http://www.vishia.org/SwEng/pictures/git-side-branch-example.jpg Image: example side branches in git]]

'''Now back to bazaar''':

John A Meinel proposed the following answer:

If you want to commit new changes based on an older revision, you generally want to start a new branch. So something like

bzr branch master feature -r OLD
cd feature
bzr commit

If you are using a checkout you can do

cd checkout
bzr branch --switch -r OLD ../master ../feature

TODO test

====Experience with large project====

* Created a side branch in another directory with
bzr branch VersionNr.

* Work, work, work, supply to customer.

* Now I want to merge most of changes on the old side branch to the actual version.

* Using Bzr-Explorer. Inside the trunk (the original tree from which the side branch was taken) press the ''merge'' button,
give the path to the side branch directory where .bzr is found. It is equal to the command:

bzr merge pathToSideBranch

* Now it shows 14 Conflicts,
* The files which are not changed from base revision to actual, but changed in side, are taken from side without further enquiry.
* The files which are changed from base to actual, and also changed in side, are stored with extension
** .BASE the common base version
** .OTHER the side branch which is merged into
** .THIS the actual version in this sandbox.
* The current file without extensions is pre-merged. If changes are detect between BASE and OTHER wich are not changed between BASE and THIS,
or if changes are detect between BASE and THIS which are not changed between BASE and OTHER, both are present in the pre-merged current file.
It is able to presume that both changes are relevant.
* But if the changes at the equal position are conflictin between BASE and THIS and BASE and OTHER, then a labeling is done in the form:

>>>>>>TREE
the = code + in + this;
======
the = code + in + other;
<<<<<<MERGE
* This parts of changes should be visualized and adjusted manually.
* It may be recommended to compare all changes accurately. Use a diff tool and compare the actual file with file.THIS, file.OTHER.
For this action I use The.file.Commander with a pre-written command to call

==diff THIS==
&dj.bat <*absFile1> <*absFile1>.THIS

==diff OTHER==
&dj.bat <*absFile1> <*absFile1>.OTHER

==diff BASE==
&dj.bat <*absFile1> <*absFile1>.BASE

==diff OTH_BASE==
&dj.bat <*absFile1>.OTHER <*absFile1>.BASE

==diff THIS_BASE==
&dj.bat <*absFile1>.THIS <*absFile1>.BASE

*+ where ''dj.bat'' is a command file to call a diff-view tool.

* declaring the conflicts are resolved with command (in bzr-explorer)

bzr resolve --all

* Press refresh firt in GUI, because it is a manual command, then the conflicts are not shown any more.

* now commit all changes.

Source-Version-Management-de

JcHartmut — Sat, 26 May 2012 22:18:57 GMT

JcHartmut: new, text parts from bazaar-page

Main Page

JcHartmut — Sat, 26 May 2012 22:15:37 GMT

JcHartmut:

This site holds information about programming for embedded software in an ObjectOriented style. Ideas and concepts of the Java programming language are integrated in this thinks. Some articles describe software-engineering-topics.

==Base links==
* [[Java4C]] - why Java-thinking and Java-using for the C-programming
* [[CRuntimeJavalike]] - A base library for embedded C-software
* [[Java2C]] - A translator from Java-sources to C-sources
* [[Component]] - Building the application with components and moduls
* [[Bazaar]] - A Source Version System

==Java4C==
* [[Java4C]] - why Java-thinking and Java-using for the C-programming
* [[SourceLinesAndDocu]] - Graphic programming (UML or other) or '''lines of code''' - what is with the documentation
* [[GraphicAndCodeGen]] - Graphical programming and code generation

==CRuntimeJavalike==
* [[CRuntimeJavalike]] - A base library for embedded C-software
===OSAL===
* [[OSAL]] - The interface to the operation system with its application layer
* basics: [[os_types_def]] // [[os_AtomicAccess]] // [[os_error]]
* somethings: [[os_mem]] // [[os_time]] // [[os_file]] // [[os_endian]]
* MultiThreading: [[os_thread]] -- [[os_waitnotify]] -- [[os_sync]] -- [[os_socket]]
* [[os_Shared_Memory]] -- [[Dual port RAM]] -- [[InterProcessCommunication]]
* [[os_driver]] operation access at driver level

==Java2C==
* [[http://www.vishia.org/Java2C www.vishia.org/Java2C]]
* [[http://sourceforge.net/projects/java2c Java2C on sourceforge]]

==Components, Dependencies==
* [[Component]] - Building the application with components and modules - common description

===Components of vishia-Software===
* [[Components of vishia-Java]] - presentation of components from all Java - sources of org/vishia
* [[Components of CRuntimeJavalike]] - presentation of components from C-sources

===Dependencies===
* [[Dependency]]

====Dependency-Topics of C====
* [[forward declaration of struct]]
* [[forward declaration of functions in header]]

====Dependency-Topics of ObjectOrientation (Java, C)====

* TODO

==Source Version Management==
* [[Source-Version-Management-de]] (german)
* [[Source-Version-Management-en]] (english)
* [[Bazaar]] - A Source Version System
* [[Bazaar-Notes]]: discussion (german) about Source-Management and directory structures

==Linux==
* [[Linux]] - Some hints for Linux usage

==The key author of this site==

has experience in embedded programming since 1977, beginning with Assembler programming with the Z80-processor. I'm working for a company in germany in themes of embedded control. This site presents experiences independently of concretely job definitions. Hartmut Schorrig, [[http://www.vishia.org www.vishia.org]]

==The mission of this site - Your contribution==

Exchange of experiences. You can take place on discussion. You can complement the text of the pages with your experience and knowledge. You can improve the appearance of the text.

It is necessary to register with a user name to this site.

Future: [[Inspector datagram]]

Os file

JcHartmut — Sun, 06 Mar 2011 19:42:12 GMT

JcHartmut: /* Comparison with Java-file-handling -locking and conclusion

==Contains==
* Handling with opened streams, adequate fopen, fread, fwrite, flock, ftell, fskip
* Handling with file entries in a directory: exists, write-ability, date last modified, length, absolute path
* supports pipes of command in/output: stdin, stdout, stderr

==Situation for embedded platforms==
A file system known from the PC-based software in C is not present in some embedded devices.

But a handling of special files may be possible. There may be present only a few files with given names, or some files in only one directory level which are stored in the RAM, a flash file system, a remote file system etc.

User software should handle with files, independently how it is deployed in the given hardware platform. If there are only special files, the user software should regard this situation using the given special file-paths while open it. But the user software should not depend on the hardware implementation of the file system. All algorithm should be able to test on PC-platform.

==Situation of standardizing in C==

===streamed file-io===

The old C knows two standard to access the content of files:

* Lo-level file-io using open, read, write with a int handle. This was the originally intension in C. This concept founds the stream-handling of UNIX using pipes, standard- and error.output on console etc.

* Buffered file-io using fopen, fread, fwrite, fflush with a structured file handle named <tt>FILE*</tt> defined in < stdio.h>. This was a second stage of file handling in C.

The interface between the linux-core and the library-layer is adequate to the lo-level-file-system.

Only the buffered file-io is usual in C-programming now. The C99-standard doesn't know the routines of the lo-level-file-io. The buffered file-io regards the <tt>stdout</tt>, <tt>stdin</tt> and <tt>stderr</tt> for piping command line applications too. But they are not the int-values 0..2. Rather than they are special FILE-objects supported by the std-library.

Any C-compiler at any embedded system may offer this file-io-standard-routines and data, but sometimes not in that way how the hardware implements it really. To access the file system which is supported by special packages the routines of the special package should be used instead. The methods are provided in adequate interfaces with adequate names of the routines, but not identical. Often the file-system-component is not integrated in the standard library of the compiler.

===Properties of files===
The query of a last-modified timestamp etc. is defined in C in the POSIX-standard with the method <tt>fstat()</tt> defined in the <tt><sys/stat.h></tt>-header. This standard is regarded in some C- and C++ compiler-libraries but it isn't standardized in the C99-standard and it isn't present in a standardized form for any platform. Therefore the POSIX-standard for that isn't able to use outside of UNIX/Linux/PC programming. There is not a really standard.

Therefore the os_file OSAL provides a able-to-use interface. The implementation can use the POSIX-standard if exists or adequate mechanism, which exists in most of file-system-components.

===File locking mechanism===
The file locking mechanism are not defined in C99. It means, it isn't defined how to program file locking for portable software. The POSIX-standard defines some mechanism, but they are not available in any cases.

The necessities of file locking are:
* Free read access to files, which are opened to write?
* Open for write exclusively or concurrently?
* If open for write concurrently, a file lock should be possible.
* If open for write concurrently, a record lock should be possible. It locks an existing range in the file.
* The locks should be removed anytime automatically if the file is closed. In this kind hangs of locks should be prevented.

This requests should be defined for portable programming.

==Comparison with Java-file-handling==
===Streamed file-io===
Java knows the <tt>java.io.InputStream</tt> and <tt>java.io.OutputStream</tt>. This both abstract classes are the basics for stream in/out, which are comparable with the lo-level file-io of C respectively the standard file-io using the <tt>FILE*</tt> descriptor, but without <tt>fprintf</tt>-capability. The last one is provided with the <tt>java.io.PrintStream</tt>, derived from java.io.OutputStream. The class java.lang.System contains three references named <tt>out</tt>, <tt>err</tt> and <tt>in</tt> of type of PrintStream respectively InputStream which represents the pipe-concept of command line invocations in the adequate way as C's <tt> stdin</tt>, <tt>stdout</tt> and <tt>stderr</tt>.

===Properties of files===

The handling with file entries in a directory is supported with the class <tt>java.io.File</tt> with its methods <tt>exists()</tt>, <tt>lastModified()</tt> etc. This class is comparable with the <tt>struct OS_FileDescription</tt> and its associated routines defined in the <tt>os_file.h</tt>.

===File locking mechanism===
The locking mechanism are defined in the classes <tt>java.nio.channels.FileLock</tt>. This class was created with the Java-version 1.4 about anno 2002.

===Conclusion===

Java provides proper functionality for all file handling requests in its standard packages. A Java-programmer can have confidence to write really portable sources. The adaption to the underlying operation system is assured from the particular Java-Virtual-Machine.

==Using os_file.h instead file handling with stdio.h==

How it is described in the chapter above, the standard-file-handling doesn't resolve the real expected functionality. Thats why the user programming should not use the standard-file-handling but the os_file-handling. The OSAL-layer adapts the real file handling of the given environment. It can do it because it is a module associated to the users system component, not only associated to the compiler provider.

Sometimes the handling of files is wrapped with functionality of a higher level than the C-standard-file-io. The user uses this wrapper instead the more lo-level C-functions. Inside the wrapper the os_file-routines are called. In that kind the user hasn't any cohesion to the os_file or standard-file handling immediately. The usage of wrappers provides a higher-level interface for the user programming.

==Description of os_file - Interface==

===Query of properties of files===

The struct <tt>OS_FileDescription</tt> contains the properties for

* fileLength
* flags for query
** exists
** canRead
** canWrite
** hidden
** directory entry or file
* timestamp last modified
* absolute (internal) path of the file
* position of name and relativ path in file to support query it.

The method <tt>os_initFileDescription(this, filepath)</tt> intializes the struct without calling the operation system. The method <tt>os_getFileDescription(this)</tt> accesses the operation system and reads the data from directory entries. The implementation uses <tt>fstat(...)</tt> if a POSIX-compatible access is available.

===stream in/out===
TODO
===file locking===
TODO

Os file

JcHartmut — Sun, 06 Mar 2011 19:29:11 GMT

JcHartmut: Situation of standardizing in C: file locking mechanism

==Contains==
* Handling with opened streams, adequate fopen, fread, fwrite, flock, ftell, fskip
* Handling with file entries in a directory: exists, write-ability, date last modified, length, absolute path
* supports pipes of command in/output: stdin, stdout, stderr

==Situation for embedded platforms==
A file system known from the PC-based software in C is not present in some embedded devices.

But a handling of special files may be possible. There may be present only a few files with given names, or some files in only one directory level which are stored in the RAM, a flash file system, a remote file system etc.

User software should handle with files, independently how it is deployed in the given hardware platform. If there are only special files, the user software should regard this situation using the given special file-paths while open it. But the user software should not depend on the hardware implementation of the file system. All algorithm should be able to test on PC-platform.

==Situation of standardizing in C==

===streamed file-io===

The old C knows two standard to access the content of files:

* Lo-level file-io using open, read, write with a int handle. This was the originally intension in C. This concept founds the stream-handling of UNIX using pipes, standard- and error.output on console etc.

* Buffered file-io using fopen, fread, fwrite, fflush with a structured file handle named <tt>FILE*</tt> defined in < stdio.h>. This was a second stage of file handling in C.

The interface between the linux-core and the library-layer is adequate to the lo-level-file-system.

Only the buffered file-io is usual in C-programming now. The C99-standard doesn't know the routines of the lo-level-file-io. The buffered file-io regards the <tt>stdout</tt>, <tt>stdin</tt> and <tt>stderr</tt> for piping command line applications too. But they are not the int-values 0..2. Rather than they are special FILE-objects supported by the std-library.

Any C-compiler at any embedded system may offer this file-io-standard-routines and data, but sometimes not in that way how the hardware implements it really. To access the file system which is supported by special packages the routines of the special package should be used instead. The methods are provided in adequate interfaces with adequate names of the routines, but not identical. Often the file-system-component is not integrated in the standard library of the compiler.

===Properties of files===
The query of a last-modified timestamp etc. is defined in C in the POSIX-standard with the method <tt>fstat()</tt> defined in the <tt><sys/stat.h></tt>-header. This standard is regarded in some C- and C++ compiler-libraries but it isn't standardized in the C99-standard and it isn't present in a standardized form for any platform. Therefore the POSIX-standard for that isn't able to use outside of UNIX/Linux/PC programming. There is not a really standard.

Therefore the os_file OSAL provides a able-to-use interface. The implementation can use the POSIX-standard if exists or adequate mechanism, which exists in most of file-system-components.

===File locking mechanism===
The file locking mechanism are not defined in C99. It means, it isn't defined how to program file locking for portable software. The POSIX-standard defines some mechanism, but they are not available in any cases.

The necessities of file locking are:
* Free read access to files, which are opened to write?
* Open for write exclusively or concurrently?
* If open for write concurrently, a file lock should be possible.
* If open for write concurrently, a record lock should be possible. It locks an existing range in the file.
* The locks should be removed anytime automatically if the file is closed. In this kind hangs of locks should be prevented.

This requests should be defined for portable programming.

==Comparison with Java-file-handling==

Java knows the <tt>java.io.InputStream</tt> and <tt>java.io.OutputStream</tt>. This both abstract classes are the basics for stream in/out, which are comparable with the lo-level file-io of C respectively the standard file-io using the <tt>FILE*</tt> descriptor, but without <tt>fprintf</tt>-capability. The last one is provided with the <tt>java.io.PrintStream</tt>, derived from java.io.OutputStream. The class java.lang.System contains three references named <tt>out</tt>, <tt>err</tt> and <tt>in</tt> of type of PrintStream respectively InputStream which represents the pipe-concept of command line invocations in the adequate way as C's <tt> stdin</tt>, <tt>stdout</tt> and <tt>stderr</tt>.

The handling with file entries in a directory is supported with the class <tt>java.io.File</tt> with its methods <tt>exists()</tt>, <tt>lastModified()</tt> etc. This class is comparable with the <tt>struct OS_FileDescription</tt> and its associated routines defined in the <tt>os_file.h</tt>.

==Using os_file.h instead file handling with stdio.h==

How it is described in the chapter above, the standard-file-handling doesn't resolve the real expected functionality. Thats why the user programming should not use the standard-file-handling but the os_file-handling. The OSAL-layer adapts the real file handling of the given environment. It can do it because it is a module associated to the users system component, not only associated to the compiler provider.

Sometimes the handling of files is wrapped with functionality of a higher level than the C-standard-file-io. The user uses this wrapper instead the more lo-level C-functions. Inside the wrapper the os_file-routines are called. In that kind the user hasn't any cohesion to the os_file or standard-file handling immediately. The usage of wrappers provides a higher-level interface for the user programming.

==Description of os_file - Interface==

===Query of properties of files===

The struct <tt>OS_FileDescription</tt> contains the properties for

* fileLength
* flags for query
** exists
** canRead
** canWrite
** hidden
** directory entry or file
* timestamp last modified
* absolute (internal) path of the file
* position of name and relativ path in file to support query it.

The method <tt>os_initFileDescription(this, filepath)</tt> intializes the struct without calling the operation system. The method <tt>os_getFileDescription(this)</tt> accesses the operation system and reads the data from directory entries. The implementation uses <tt>fstat(...)</tt> if a POSIX-compatible access is available.

===stream in/out===
TODO
===file locking===
TODO

Forward declaration of functions in header

JcHartmut — Thu, 03 Mar 2011 08:10:08 GMT

JcHartmut: first, new text

==Forward declarations of functions in C-header==

The forward declaration assures the correct usage of argument types and defines the return type of a method.

* The forward declaration should be written only 1 time in 1 header-file. It is a bad style to declare a method anywhere where it is used. The chance of mistakes is given then:

* If the forward declaration is read from compiler before the function is compiled the compiler can be check whether it is correct. If the forward declaration isn't contain, because it is written in a foreign headerfile, the compiler can't check the correctness. That is self-fool.

It is a good style that the header which declares the function has the same name as the source-file which contains the implementation:

MyModule_CPN.h
...
float myFunction(float* inputs, int nrofInputs);

MyModule_CPN.c
...
float myFunction(float* inputs, int nrofInputs)
{ //implementation
}

This approuch is necessary to concluse of the dependencies from included headerfiles to the need compilation units, maybe provided by libraries.

If alternating implementations exists, either they should be contained in files with the same name but in different directories. It is assumed, that this sources are compiled in several libraries. Or a abbreviating but recognize-able name should be used, for example <tt>MyModule_A_CMPN.c</tt>.

If more as one C-file should be assiciated to one headerfile, it is a issue of sub-modules. Then derived names for the source-files should be used:

MyModule_CPN.h
PartA_MyModule_CPN.c
PartB_MyModule_CPN.c

In this article a suffix-style for naming is used: <tt>CPN</tt> is a placeholder for a short identifier for the ComPoNent where it is member of. It is the suffix. A subcomponent is existing in a component, it is written as prefix. In opposite, often a prefix-style is used: <tt>CPN_MyModule_PartA.c</tt>. The prefix style has the advantage of a better sort in alphabetic order. But the read-ability is wors:

* Suffix-style: <tt>...PartA_MyModu...</tt>: okay, it's PartA in the given known environment.
* Prefix-style: <tt>...CPN_MyModu...</tt>: what's that, oh, my known component, should read the next <tt>...le_PartA</tt>.

Main Page

JcHartmut — Thu, 03 Mar 2011 07:39:22 GMT

JcHartmut: new pages about dependency planned

This site holds information about programming for embedded software in an ObjectOriented style. Ideas and concepts of the Java programming language are integrated in this thinks. Some articles describe software-engineering-topics.

==Base links==
* [[Java4C]] - why Java-thinking and Java-using for the C-programming
* [[CRuntimeJavalike]] - A base library for embedded C-software
* [[Java2C]] - A translator from Java-sources to C-sources
* [[Component]] - Building the application with components and moduls
* [[Bazaar]] - A Source Version System

==Java4C==
* [[Java4C]] - why Java-thinking and Java-using for the C-programming

==CRuntimeJavalike==
* [[CRuntimeJavalike]] - A base library for embedded C-software
===OSAL===
* [[OSAL]] - The interface to the operation system with its application layer
* [[os_types_def]] - A header-file define all basic types and macros

==Java2C==
* [[http://www.vishia.org/Java2C www.vishia.org/Java2C]]
* [[http://sourceforge.net/projects/java2c Java2C on sourceforge]]

==Components, Dependencies==
* [[Component]] - Building the application with components and modules - common description

===Components of vishia-Software===
* [[Components of vishia-Java]] - presentation of components from all Java - sources of org/vishia
* [[Components of CRuntimeJavalike]] - presentation of components from C-sources

===Dependencies===
* [[Dependency]]

====Dependency-Topics of C====
* [[forward declaration of struct]]
* [[forward declaration of functions in header]]

====Dependency-Topics of ObjectOrientation (Java, C)====

* TODO

==Bazaar==
* [[Bazaar]] - A Source Version System
* [[Bazaar-Notes]]: discussion (german) about Source-Management and directory structures

==The key author of this site==

has experience in embedded programming since 1977, beginning with Assembler programming with the Z80-processor. I'm working for a company in germany in themes of embedded control. This site presents experiences independently of concretely job definitions. Hartmut Schorrig, [[http://www.vishia.org www.vishia.org]]

==The mission of this site - Your contribution==

Exchange of experiences. You can take place on discussion. You can complement the text of the pages with your experience and knowledge. You can improve the appearance of the text.

It is necessary to register with a user name to this site.

OSAL

JcHartmut — Wed, 02 Mar 2011 13:29:07 GMT

JcHartmut: navigation

==Navigation==
* up: [[Main_Page]]
* down basics: [[os_types_def]] // [[os_AtomicAccess]] // [[os_error]]
* somethings: [[os_mem]] // [[os_time]] // [[os_file]] // [[os_endian]]
* MultiThreading: [[os_thread]] -- [[os_waitnotify]] -- [[os_sync]] -- [[os_socket]]

==Overview==
@ident=OSAL

'''OS-independent programming'''

Some programmers work for their ''project''. It may be running on a special hardware with a special
operation system, mostly a RTOS (Real Time Operation System).
The tests are executed at the target hardware - reality tests.
Thus the thought is ''C is not C, any target system needs its own slang (dialect)''.

What is missing? Compilation of the sources with a proper Integrated Development Environment (IDE).
On the PCs, there are some good IDEs, such as Eclipse, Microsoft Visual Studio etc.
Mostly, the IDEs for a special hardware are good, but not so good like PC-platform-tools.

What is also missing? Functional testing the algorithm. It isn't a real-time test. But
it may be essential.

What is the effort? The algorithm in C need to compile in a PC-environment. It should be able to test,
not in real-time, maybe only in one thread or more.
For this reason the OS-functionality should be able to use at the test-environment.

What is the result:
* Well functional tested algorithms
* Faster writing, reorganization, optimizing and gardening of sources, because the PC-platform
is able to use for faster work.
* Better sources.

The tests on the target-platform are reduced to test the real platform problems, not to test the algorithm basically.

'''Need of special Operation System capabilities'''

Most of the Operation Systems are similar in a large way of thinking. All of these support multi-threading,
with mutex etc. Most of them have a file system in a adequate kind etc.

The differences are: They should be support the hardware platform with different processors, different
equipment in RAM, ROM, different I/O. But the user programming shouldn't consider all of them so far.
The user programming should be realized in a more abstract shell. This means the RTOS should be proper
for the hardware, but it should not have to much special features for the user programming. It may be
useful only for driver or interrupt-level-programming.

Conclusion: The user programming should use unified interfaces to the operation system.

==OSAL-Level in the CRuntimeJavalike==

Programming in Java is OS-independent in the first way. In that mind, the CRuntimeJavalike needs a
''Operation System Adaption Level'' (OSAL).

The given OSAL is layered closed to a ''not-only Java-like''-programming. It supports standard C
functionality. The typical Java-like functions like ThreadJc based on this OSAL-interface.

A first idea in the past was to introduce the OSAL-level in the OS-oriented classes like ThreadJc, ObjectJc
with its ''synchronized_ObjectJc''-methods etc. But a Java-independent definition
of the OSAL-interface provides some use-cases for the non-java-like-oriented programming, too.
So it is implemented independently from Java-like-C-classes.

==Common headers==

An interface in C-language is established in header-files. Most of compiler-tool-associated header-files
declare the same things, but in their own files in a maybe different form. So the risk of
little differences are given.

Instead all OS-interface-functions should be declared in the same header-files, independent of
the current used operation system. The implementation of the OSAL should use this files and adapt
their OS-functions.

All of those OS-independent common header files are declared
in the folder ,,CRuntimeJavalike/OSAL/inc,,. The current file list is:

os_adapter.h
os_endian.h
os_file.h.bak
os_mem.h
os_serror.h
os_socket.h
os_sync.h
os_time.h.bak
os_waitnotify.h
os_error.h
os_file.h
os_thread.h
os_AtomicAccess.h
os_time.h

==Different headers==

Some things should be declared or defined in a OS-specific way. The same things should be defined
in a different kind, appropriate to the operation system and the compiler properties.

The most important file doing this is the ,,os_types_def.h,,. The same file-name is used
in different directories, all specific for OS and compiler. It defines the same things in a different way.

The most noticeable property is the definition of the OS- and compiler-depending definition of
fix-size-integer types. The C99-standard suggests the usage of ,,int32_t,, etc. But most of the
programmers had created their own standard before or simultaneous to the C99-Standard. These types are present
in many sources. They are defined in some special headers like ,,standard.h,,,
which is anytime ,,mystandard.h,,. These types are defined in the ,,os_types_def.h,,.

There are some things defined there in addition:
* little/big endian defines, processors are different.
* C++-keyword for C-usage, especially ,,bool,,, ,,true,,, ,,false,,.
* The macro METHOD_C which maybe ,,extern "C",, or not.
* A ,,MemUnit,,-type. It is the type which describes one element in the address spaces.
It is not a ,,char,, anytime, not in Signal-processors.

==C-basics==

There are some things, which may defined in a good C-design able to use for the OSAL-level too.
This C-basics are provided OS-independently in the following files (definition and implementation):

fw_Exception.h
fw_Exception.c
fw_LogMessage.h
fw_LogMessage.c
fw_Va_list.h
fw_formatter.c
fw_Formatter.h
fw_SimpleC.c
fw_SimpleC.h
fw_MemC.h
fw_MemC.c
objectBaseC.h
fw_Object.c
fw_timeconversions.h
fw_timeconversions.c
fw_ThreadContext.h
fw_String.h
fw_threadContext.c

This so-named ''framework''-level is independent from the OSAL-adaption and it is ready to use
for the OS-adaption.

==OS-adaption for threads==

see ,,os_thread.h,,

OSAL

JcHartmut — Wed, 02 Mar 2011 08:01:35 GMT

JcHartmut: first, copied from vishia

==Overview==
@ident=OSAL

'''OS-independent programming'''

Some programmers work for their ''project''. It may be running on a special hardware with a special
operation system, mostly a RTOS (Real Time Operation System).
The tests are executed at the target hardware - reality tests.
Thus the thought is ''C is not C, any target system needs its own slang (dialect)''.

What is missing? Compilation of the sources with a proper Integrated Development Environment (IDE).
On the PCs, there are some good IDEs, such as Eclipse, Microsoft Visual Studio etc.
Mostly, the IDEs for a special hardware are good, but not so good like PC-platform-tools.

What is also missing? Functional testing the algorithm. It isn't a real-time test. But
it may be essential.

What is the effort? The algorithm in C need to compile in a PC-environment. It should be able to test,
not in real-time, maybe only in one thread or more.
For this reason the OS-functionality should be able to use at the test-environment.

What is the result:
* Well functional tested algorithms
* Faster writing, reorganization, optimizing and gardening of sources, because the PC-platform
is able to use for faster work.
* Better sources.

The tests on the target-platform are reduced to test the real platform problems, not to test the algorithm basically.

'''Need of special Operation System capabilities'''

Most of the Operation Systems are similar in a large way of thinking. All of these support multi-threading,
with mutex etc. Most of them have a file system in a adequate kind etc.

The differences are: They should be support the hardware platform with different processors, different
equipment in RAM, ROM, different I/O. But the user programming shouldn't consider all of them so far.
The user programming should be realized in a more abstract shell. This means the RTOS should be proper
for the hardware, but it should not have to much special features for the user programming. It may be
useful only for driver or interrupt-level-programming.

Conclusion: The user programming should use unified interfaces to the operation system.

==OSAL-Level in the CRuntimeJavalike==

Programming in Java is OS-independent in the first way. In that mind, the CRuntimeJavalike needs a
''Operation System Adaption Level'' (OSAL).

The given OSAL is layered closed to a ''not-only Java-like''-programming. It supports standard C
functionality. The typical Java-like functions like ThreadJc based on this OSAL-interface.

A first idea in the past was to introduce the OSAL-level in the OS-oriented classes like ThreadJc, ObjectJc
with its ''synchronized_ObjectJc''-methods etc. But a Java-independent definition
of the OSAL-interface provides some use-cases for the non-java-like-oriented programming, too.
So it is implemented independently from Java-like-C-classes.

==Common headers==

An interface in C-language is established in header-files. Most of compiler-tool-associated header-files
declare the same things, but in their own files in a maybe different form. So the risk of
little differences are given.

Instead all OS-interface-functions should be declared in the same header-files, independent of
the current used operation system. The implementation of the OSAL should use this files and adapt
their OS-functions.

All of those OS-independent common header files are declared
in the folder ,,CRuntimeJavalike/OSAL/inc,,. The current file list is:

os_adapter.h
os_endian.h
os_file.h.bak
os_mem.h
os_serror.h
os_socket.h
os_sync.h
os_time.h.bak
os_waitnotify.h
os_error.h
os_file.h
os_thread.h
os_AtomicAccess.h
os_time.h

==Different headers==

Some things should be declared or defined in a OS-specific way. The same things should be defined
in a different kind, appropriate to the operation system and the compiler properties.

The most important file doing this is the ,,os_types_def.h,,. The same file-name is used
in different directories, all specific for OS and compiler. It defines the same things in a different way.

The most noticeable property is the definition of the OS- and compiler-depending definition of
fix-size-integer types. The C99-standard suggests the usage of ,,int32_t,, etc. But most of the
programmers had created their own standard before or simultaneous to the C99-Standard. These types are present
in many sources. They are defined in some special headers like ,,standard.h,,,
which is anytime ,,mystandard.h,,. These types are defined in the ,,os_types_def.h,,.

There are some things defined there in addition:
* little/big endian defines, processors are different.
* C++-keyword for C-usage, especially ,,bool,,, ,,true,,, ,,false,,.
* The macro METHOD_C which maybe ,,extern "C",, or not.
* A ,,MemUnit,,-type. It is the type which describes one element in the address spaces.
It is not a ,,char,, anytime, not in Signal-processors.

==C-basics==

There are some things, which may defined in a good C-design able to use for the OSAL-level too.
This C-basics are provided OS-independently in the following files (definition and implementation):

fw_Exception.h
fw_Exception.c
fw_LogMessage.h
fw_LogMessage.c
fw_Va_list.h
fw_formatter.c
fw_Formatter.h
fw_SimpleC.c
fw_SimpleC.h
fw_MemC.h
fw_MemC.c
objectBaseC.h
fw_Object.c
fw_timeconversions.h
fw_timeconversions.c
fw_ThreadContext.h
fw_String.h
fw_threadContext.c

This so-named ''framework''-level is independent from the OSAL-adaption and it is ready to use
for the OS-adaption.

==OS-adaption for threads==

see ,,os_thread.h,,

Component

JcHartmut — Sat, 26 Feb 2011 14:25:20 GMT

JcHartmut: /* Navigation */

==Navigation==
* up: [[Main_Page]]
* down: [[Components_of_vishia-Java]] [[Components_of_CRuntimeJavalike]]

==Components and modules, re-using==

A software should consist of more as one component. Each component should be able to describe, program and test independent of the application which uses it. A component may be able to use in several applications. Then it is reuseable.

Modules are the finer granularity inside components or inside the core of the application. Each module should be able to describe, program and test independently too. Modules may be one C/h-file or a package in Java or some related files.

A class in ObjectOrientation is the more finer granularity inside modules. A class in the C-programming is a logical coherence between one data structure and related subroutines. One class may be presented exactly with one source-file.

==Dependencies between components, modules, classes==

If another class is used inside a class, it depends on it. Formally it depends on the signature of the methods of the class. Really the functionality depends on the functionality of the called methods.

For a independent test of a class, module or component it may be necessary to abstract the functionality of the depending stuff. The behavior of the depending stuff should be replaced by a simulation or emulation.

There are '''horizontal and vertical dependencies''': If a class/module/component can be created, described and tested independent on another class/module/component, it is deeper in vertical or parallel in horizontal layer. If a class/module/component needs another one, it is above that in vertical layer. ''It needs'' means, in the real application it is associated to it and calls some methods from there. For the independently test all needed classes/modules/components may be able to replace.

===Interfaces as dependency-breaker===

There is a problem: Module_A needs some methods from Module_B and on the other hand Module_B needs some things from Module_A. Both modules are parallel in layer, but there are not able to develop and test independently.

Either the both modules are not two separated modules, the functionality should be combined in one module. - Or it should be separated using interfaces.

The ''interface'' is a language-element of Java. It defines methods with its signature, but without implementation. The description, "''what should the method do, which argument values are expectable, meaning of the return value''" belongs to the method anyway. In C++ interfaces are able to create in a similar kind as Java. It is a class with only virtual abstract methods and without any implementation:

class InterfaceExample { //C++-interface
virtual int aMethod(int arg) = 0;
};

====Classic C - Headerfiles as interface====

The classic C programming knows headerfiles, which ones play the role of interfaces: Function prototypes has the same appearance as a method definition in a Java-interface or a virtual abstract methods:

extern int aFunction(int arg);

The difference to Java and C++-virtual-methods is: It is static linked. There can be only one implementation in a executable, whereby in Java and C++ the interface can be implement by several classes which are instantiated independently. It is a ''dynamic link''.

But the principle of dependency-break is the same.

====Classic C- struct forward declaration as dependency break====

In C and C++ there is a nice possibility to prevent to many include-necessities:

struct TheType_t;

typedef struct Example_t{
struct TheType_t* pointer;
} Example;

Inside the Example-struct a pointer of TheType is need. But <tt>TheType</tt> itself may left unknown. It isn't necessary to know the type while compiling this struct. It is not necessary to include the typedef of <tt>TheType</tt>

If the pointer is used in the implementation (the C-file), then the type should be known. The implementation-File includes the definition of:

typedef struct TheType_t{
int someStuff;
}Thetype;

Now the compiler checks the matching of <tt>struct TheType_t</tt> to <tt>TheType</tt> with its given definition. The <tt>TheType_t</tt> is the tag-name of the struct where <tt>TheType</tt> is the really type name. The writing-style with <tt>_t</tt>-suffix is recommended and usual but not a fix rule.

The forward declaration of a pointer-type straightens a complex dependencies of header files. In Java there is not a adequate possibility. A Java-interface is the way of straighten still.

==Criterion for Components==
* Able to define and describe as entity.
* Able to test as entity.
* Dependencies of parts to other components: If any new part creates a new dependency to a foreign component, it should be realized as critical. Either the new dependency is desired, or the part should not be a part of this component.
* Conglomerate of several functionality: It is okay, if the modules doesn't need other components (see ''dependencies''). A component can contain a functionality, which is not need in the typical use-cases, but it is offered for special usages.
* Self-reliance: The same functionality should not scattered to several components. Only one component should be responsible to that functionality.

Component

JcHartmut — Sat, 26 Feb 2011 14:22:26 GMT

JcHartmut: /* Links-down */

==Navigation==
* up: mainPage
* down: [[Components_of_vishia-Java]] [[Components_of_CRuntimeJavalike]]

==Components and modules, re-using==

A software should consist of more as one component. Each component should be able to describe, program and test independent of the application which uses it. A component may be able to use in several applications. Then it is reuseable.

Modules are the finer granularity inside components or inside the core of the application. Each module should be able to describe, program and test independently too. Modules may be one C/h-file or a package in Java or some related files.

A class in ObjectOrientation is the more finer granularity inside modules. A class in the C-programming is a logical coherence between one data structure and related subroutines. One class may be presented exactly with one source-file.

==Dependencies between components, modules, classes==

If another class is used inside a class, it depends on it. Formally it depends on the signature of the methods of the class. Really the functionality depends on the functionality of the called methods.

For a independent test of a class, module or component it may be necessary to abstract the functionality of the depending stuff. The behavior of the depending stuff should be replaced by a simulation or emulation.

There are '''horizontal and vertical dependencies''': If a class/module/component can be created, described and tested independent on another class/module/component, it is deeper in vertical or parallel in horizontal layer. If a class/module/component needs another one, it is above that in vertical layer. ''It needs'' means, in the real application it is associated to it and calls some methods from there. For the independently test all needed classes/modules/components may be able to replace.

===Interfaces as dependency-breaker===

There is a problem: Module_A needs some methods from Module_B and on the other hand Module_B needs some things from Module_A. Both modules are parallel in layer, but there are not able to develop and test independently.

Either the both modules are not two separated modules, the functionality should be combined in one module. - Or it should be separated using interfaces.

The ''interface'' is a language-element of Java. It defines methods with its signature, but without implementation. The description, "''what should the method do, which argument values are expectable, meaning of the return value''" belongs to the method anyway. In C++ interfaces are able to create in a similar kind as Java. It is a class with only virtual abstract methods and without any implementation:

class InterfaceExample { //C++-interface
virtual int aMethod(int arg) = 0;
};

====Classic C - Headerfiles as interface====

The classic C programming knows headerfiles, which ones play the role of interfaces: Function prototypes has the same appearance as a method definition in a Java-interface or a virtual abstract methods:

extern int aFunction(int arg);

The difference to Java and C++-virtual-methods is: It is static linked. There can be only one implementation in a executable, whereby in Java and C++ the interface can be implement by several classes which are instantiated independently. It is a ''dynamic link''.

But the principle of dependency-break is the same.

====Classic C- struct forward declaration as dependency break====

In C and C++ there is a nice possibility to prevent to many include-necessities:

struct TheType_t;

typedef struct Example_t{
struct TheType_t* pointer;
} Example;

Inside the Example-struct a pointer of TheType is need. But <tt>TheType</tt> itself may left unknown. It isn't necessary to know the type while compiling this struct. It is not necessary to include the typedef of <tt>TheType</tt>

If the pointer is used in the implementation (the C-file), then the type should be known. The implementation-File includes the definition of:

typedef struct TheType_t{
int someStuff;
}Thetype;

Now the compiler checks the matching of <tt>struct TheType_t</tt> to <tt>TheType</tt> with its given definition. The <tt>TheType_t</tt> is the tag-name of the struct where <tt>TheType</tt> is the really type name. The writing-style with <tt>_t</tt>-suffix is recommended and usual but not a fix rule.

The forward declaration of a pointer-type straightens a complex dependencies of header files. In Java there is not a adequate possibility. A Java-interface is the way of straighten still.

==Criterion for Components==
* Able to define and describe as entity.
* Able to test as entity.
* Dependencies of parts to other components: If any new part creates a new dependency to a foreign component, it should be realized as critical. Either the new dependency is desired, or the part should not be a part of this component.
* Conglomerate of several functionality: It is okay, if the modules doesn't need other components (see ''dependencies''). A component can contain a functionality, which is not need in the typical use-cases, but it is offered for special usages.
* Self-reliance: The same functionality should not scattered to several components. Only one component should be responsible to that functionality.

Component

JcHartmut — Sat, 26 Feb 2011 14:19:20 GMT

JcHartmut: /* Criterion for Components */

==Links-down==
* [[Components of vishia-Java]]
* [[Components of CRuntimeJavalike]]

==Components and modules, re-using==

A software should consist of more as one component. Each component should be able to describe, program and test independent of the application which uses it. A component may be able to use in several applications. Then it is reuseable.

Modules are the finer granularity inside components or inside the core of the application. Each module should be able to describe, program and test independently too. Modules may be one C/h-file or a package in Java or some related files.

A class in ObjectOrientation is the more finer granularity inside modules. A class in the C-programming is a logical coherence between one data structure and related subroutines. One class may be presented exactly with one source-file.

==Dependencies between components, modules, classes==

If another class is used inside a class, it depends on it. Formally it depends on the signature of the methods of the class. Really the functionality depends on the functionality of the called methods.

For a independent test of a class, module or component it may be necessary to abstract the functionality of the depending stuff. The behavior of the depending stuff should be replaced by a simulation or emulation.

There are '''horizontal and vertical dependencies''': If a class/module/component can be created, described and tested independent on another class/module/component, it is deeper in vertical or parallel in horizontal layer. If a class/module/component needs another one, it is above that in vertical layer. ''It needs'' means, in the real application it is associated to it and calls some methods from there. For the independently test all needed classes/modules/components may be able to replace.

===Interfaces as dependency-breaker===

There is a problem: Module_A needs some methods from Module_B and on the other hand Module_B needs some things from Module_A. Both modules are parallel in layer, but there are not able to develop and test independently.

Either the both modules are not two separated modules, the functionality should be combined in one module. - Or it should be separated using interfaces.

The ''interface'' is a language-element of Java. It defines methods with its signature, but without implementation. The description, "''what should the method do, which argument values are expectable, meaning of the return value''" belongs to the method anyway. In C++ interfaces are able to create in a similar kind as Java. It is a class with only virtual abstract methods and without any implementation:

class InterfaceExample { //C++-interface
virtual int aMethod(int arg) = 0;
};

====Classic C - Headerfiles as interface====

The classic C programming knows headerfiles, which ones play the role of interfaces: Function prototypes has the same appearance as a method definition in a Java-interface or a virtual abstract methods:

extern int aFunction(int arg);

The difference to Java and C++-virtual-methods is: It is static linked. There can be only one implementation in a executable, whereby in Java and C++ the interface can be implement by several classes which are instantiated independently. It is a ''dynamic link''.

But the principle of dependency-break is the same.

====Classic C- struct forward declaration as dependency break====

In C and C++ there is a nice possibility to prevent to many include-necessities:

struct TheType_t;

typedef struct Example_t{
struct TheType_t* pointer;
} Example;

Inside the Example-struct a pointer of TheType is need. But <tt>TheType</tt> itself may left unknown. It isn't necessary to know the type while compiling this struct. It is not necessary to include the typedef of <tt>TheType</tt>

If the pointer is used in the implementation (the C-file), then the type should be known. The implementation-File includes the definition of:

typedef struct TheType_t{
int someStuff;
}Thetype;

Now the compiler checks the matching of <tt>struct TheType_t</tt> to <tt>TheType</tt> with its given definition. The <tt>TheType_t</tt> is the tag-name of the struct where <tt>TheType</tt> is the really type name. The writing-style with <tt>_t</tt>-suffix is recommended and usual but not a fix rule.

The forward declaration of a pointer-type straightens a complex dependencies of header files. In Java there is not a adequate possibility. A Java-interface is the way of straighten still.

==Criterion for Components==
* Able to define and describe as entity.
* Able to test as entity.
* Dependencies of parts to other components: If any new part creates a new dependency to a foreign component, it should be realized as critical. Either the new dependency is desired, or the part should not be a part of this component.
* Conglomerate of several functionality: It is okay, if the modules doesn't need other components (see ''dependencies''). A component can contain a functionality, which is not need in the typical use-cases, but it is offered for special usages.
* Self-reliance: The same functionality should not scattered to several components. Only one component should be responsible to that functionality.

Component

JcHartmut — Sat, 26 Feb 2011 10:13:52 GMT

JcHartmut:

Components of vishia-Java

JcHartmut — Fri, 25 Feb 2011 20:17:39 GMT

JcHartmut: Dependencies of ZBNF

==Overview==
vishia-Java is a tree of Java-files in the package-structure ''org/vishia/stuff''. All files are written by Hartmut Schorrig, www.vishia.org. They are used in some applications in profession too (with second license model). It is a conglomeration of different things, of course.

The usage of all files as jar-library if only a few files are needed - it isn't optimal:
* The usage as library will be proper, if an extrinsic application will use them as it is.
* If one of developers uses a component in another self-programmed application, it is self-evident to improve the used component with the challenges of the application. In that case the source should be present to check, change and improve.
* But on the other hand, if an extrinsic application should use that components proper, it should be well tested in a defined environment. A conglomeration can't be tested well enough.

Therefore that Java-sources are separated in some components. Any of the named component is available as a bazaar archive to work with sources. Any of this components are available as a download-file with some test environments as a application - or some test-Java-files exist.

This components are presented in the next chapters:

==srcJava_ZBNF==
* distribution on [[http://sf.net/projects/zbnf sf.net/projects/zbnf]]
* bazaar-archive on [[https://launchpad.net/zbnf/srcjava.zbnf launchpad.net/zbnf/srcjava.zbnf]]
* description, home-site on [[http://www.vishia.org/ZBNF www.vishia.org/ZBNF]]
Content of the distribution:
* The ZBNF-Parser with this Java-soruce is able to use discrete to convert plain-text but well-syntactical files into XML.
* The Java-sources includes a tool ''Header2Reflection'' which translates C/C++-headerfiles to C-files, which represents reflection-information about the data structures. It is used in a ''ReflectPro''-suite.
* A ''Zmake''-Tool is assiciated there. It converts simple make-prescripts to [[http://en.wikipedia.org/wiki/Apache_Ant ANT]]-make-files.

Further usage:
* The ZBNF is used in almost all applications of the author. It is because the applications translates some texts (for example Java2C), it needs config-files (GUI) etc.

Includes:
* A commandline calling argument preparer is included in the srcJava_ZBNF-package between it is the core-package of all applications.
* Some util-components are included.
* A MessageDispatcher which separates output messages (logs, able to use for embedded applications too) is contained there.

Dependencies:
* This component has not any dependencies to any foreign component. Only standard-Java-classes are used.

==vishiaJava_Util==

TODO

==vishiaJava_Java2C==
TODO

==vishiaJava_GUI==
TODO

Component

JcHartmut — Fri, 25 Feb 2011 20:13:34 GMT

JcHartmut: chapter Criterion for Components

* [[Components of vishia-Java]]
* [[Components of CRuntimeJavalike]]

==Components and modules, re-using==

A software should consist of more as one component. Each component should be able to describe, program and test independent of the application which uses it. A component may be able to use in several applications. Then it is reuseable.

Modules are the finer granularity inside components or inside the core of the application. Each module should be able to describe, program and test independently too. Modules may be one C/h-file or a package in Java or some related files.

A class in ObjectOrientation is the more finer granularity inside modules. A class in the C-programming is a logical coherence between one data structure and related subroutines. One class may be presented exactly with one source-file.

==Dependencies between components, modules, classes==

If another class is used inside a class, it depends on it. Formally it depends on the signature of the methods of the class. Really the functionality depends on the functionality of the called methods.

For a independent test of a class, module or component it may be necessary to abstract the functionality of the depending stuff. The behavior of the depending stuff should be replaced by a simulation or emulation.

There are '''horizontal and vertical dependencies''': If a class/module/component can be created, described and tested independent on another class/module/component, it is deeper in vertical or parallel in horizontal layer. If a class/module/component needs another one, it is above that in vertical layer. ''It needs'' means, in the real application it is associated to it and calls some methods from there. For the independently test all needed classes/modules/components may be able to replace.

===Interfaces as dependency-breaker===

There is a problem: Module_A needs some methods from Module_B and on the other hand Module_B needs some things from Module_A. Both modules are parallel in layer, but there are not able to develop and test independently.

Either the both modules are not two separated modules, the functionality should be combined in one module. - Or it should be separated using interfaces.

The ''interface'' is a language-element of Java. It defines methods with its signature, but without implementation. The description, "''what should the method do, which argument values are expectable, meaning of the return value''" belongs to the method anyway. In C++ interfaces are able to create in a similar kind as Java. It is a class with only virtual abstract methods and without any implementation:

class InterfaceExample { //C++-interface
virtual int aMethod(int arg) = 0;
};

====Classic C - Headerfiles as interface====

The classic C programming knows headerfiles, which ones play the role of interfaces: Function prototypes has the same appearance as a method definition in a Java-interface or a virtual abstract methods:

extern int aFunction(int arg);

The difference to Java and C++-virtual-methods is: It is static linked. There can be only one implementation in a executable, whereby in Java and C++ the interface can be implement by several classes which are instantiated independently. It is a ''dynamic link''.

But the principle of dependency-break is the same.

====Classic C- struct forward declaration as dependency break====

In C and C++ there is a nice possibility to prevent to many include-necessities:

struct TheType_t;

typedef struct Example_t{
struct TheType_t* pointer;
} Example;

Inside the Example-struct a pointer of TheType is need. But <tt>TheType</tt> itself may left unknown. It isn't necessary to know the type while compiling this struct. It is not necessary to include the typedef of <tt>TheType</tt>

If the pointer is used in the implementation (the C-file), then the type should be known. The implementation-File includes the definition of:

typedef struct TheType_t{
int someStuff;
}Thetype;

Now the compiler checks the matching of <tt>struct TheType_t</tt> to <tt>TheType</tt> with its given definition. The <tt>TheType_t</tt> is the tag-name of the struct where <tt>TheType</tt> is the really type name. The writing-style with <tt>_t</tt>-suffix is recommended and usual but not a fix rule.

The forward declaration of a pointer-type straightens a complex dependencies of header files. In Java there is not a adequate possibility. A Java-interface is the way of straighten still.

==Criterion for Components==
* Able to define and describe as entity.
* Able to test as entity.
* Dependencies of parts to other components: If any new part creates a new dependency to a foreign component, it should be realized as critical. Either the new dependency is desired, or the part should not be a part of this component.

Main Page

JcHartmut — Fri, 25 Feb 2011 19:53:05 GMT

JcHartmut: links

Component

JcHartmut — Fri, 25 Feb 2011 04:55:06 GMT

JcHartmut: first text

==Components and modules, re-using==

A software should consist of more as one component. Each component should be able to describe, program and test independently of the application which uses it. A component may be able to use in several applications. Then it is reuseable.

Modules are the finer granularity inside components or inside the core of the application. Each module should be able to describe, program and test independently too. Modules may be one C/h-file or a package in Java or some related files.

A class in ObjectOrientation is the more finer granularity inside modules. A class in the C-programming is a logical coherence between one data structure and related subroutines. One class may be presented exactly with one source-file.

==Dependencies between components, modules, classes==

If another class is used inside a class, it depends of it. Formally it depends of the signature of the methods of the class. Really the functionality depends of the functionality of the called methods.

For a independently test of a class it may be necessary to abstract of the functionality of a related class. The behavior of the related class can be replaced by a simulation or emulation.

The same thinks are valid for modules and components, only more complex.

There are '''horizontal and vertical dependencies''': If a class/module/component can be created, described and tested independently of another class/module/component, it is deeper in vertical or parallel in horizontal layer. If a class/module/component needs another, it is above in vertical layer. ''It needs'' means, in the real application it is associated to it and calls some methods there. For the independently test all needed classes/modules/components may be able to replace.

===Interfaces are dependency-breaker===

It is a problem if Module_A needs some methods from Module_B and in the other direction too. Both modules are parallel in layer, but there are not able to develop and test independently. In C the implementation of Module_A includes the headerfiles from Module_B and vice-versa.

Main Page

JcHartmut — Fri, 25 Feb 2011 04:23:09 GMT

JcHartmut: structure of links

Java4C

JcHartmut — Fri, 25 Feb 2011 04:15:43 GMT

JcHartmut: copied from the main page

==Java4C==
Goals:
* Using Java-programming language for embedded software in cooperation with C (and C++-) software.
* Using a ObjectOriented style of programming also in C!
* Using Java-like basic routines inclusive operation-system-calls.
* Using Java for program and test, and translate the sources to C.

===Why Java?===
Java is not only a language for internet applications. Java is a programming system for common usage. The first approach to develop Java in 1994 was: Creation of a portable language for embedded applications. Java is used in some embedded applications like mobil phones, routers. It is present with a ''JTRES'': ''Java Technology for Realtime Embedded Systems'' provided by companies like Sun/Oracle, Aicas, Aonix/Atego and others.

The Java-syntax for expressions is similar like C. Java is strong declarative, like C. The differences to C are:
* ObjectOrientation
* It is a Language of a new generation. The C-style of programming was born in 1970 with orientation to structured programming. Java was born in 1994.
* Java supports a better test of algorithms. If there are any errors for example in the addressing (indexing) of arrays, it is detected safely in runtime. The algorithms need not be tested step by step to prevent such errors. A paradigma ''compile 'n run'' can be used. The time for testing can be reduced drasticly without reducing the quality of software respectively more complex algorithms can be tested in the same time like simple algorithm in C or C++.

Java uses dynamic data. The approach of dynamic data helps to handle with variegated data in many threads in large applications. For example the String-processing needs dynamic memory. But it is also possible to handle with static data (allocated on startup). For example, String processing using a StringBuilder-instance and the CharSequence-interface can execute without allocation of memory. Static data are proper to use for embedded systems often.

===Why not C++?===
C++ is ObjectOriented and a modern programming language too. It is downward-compatible with C.

But the usual programming style in C++ divergates from the style in C. There are handled with dynamic memory in some basic classes, complex constructs using the template concept are usual. An ordinary C++-program can't be used for embedded programming often.

The disadvantages of the C-language: Unsafe pointer arithmetic, arbitrary casts, unchecked array addressing are all present in C++ too. C++ doesn't help for testing such errors like C.

Bazaar-Notes

JcHartmut — Wed, 23 Feb 2011 08:10:01 GMT

JcHartmut: sharedReopositories

@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

==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 [[https://bitbucket.org/jchartmut/cruntimejavalike 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? Nur Quellen im SCM?==

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.

==Mehrere Produkte aus einem Repository==
Das große Thema ist Wiederverwendung (Reuse). Häufig zu Beobachten: Reuse besteht aus copy'n paste and change. Die Quellen wandern also irgendwo anders hin, bzgl SCM auch für den einzelnen besser zu beherrschen - man muss sich nur mit dem beschäftigen, was man selbst hat.

Das ist keine wirkliche Wiederverwendung. Der wirkliche Vorteil des reuse geht dabei verloren:
* Fehler, die in Produkten festgestellt werden, werden in den jeweiligen Modulen korrigiert und sind dann automatisch auch für andere Produkte mit korrigiert, obwohl sie dort ggf. noch gar nicht aufgefallen sind.

Für true-reuse ist es notwendig, die Software-Module so zu bauen, dass sie '''unverändert''' in verschiedenen Produkten verwendbar sind und das Änderungen für alle Produkte nutzbar sind. Das ist eine Frage der Schnittstellen. Die Schnittstellen sind viel wichtiger als die innere Funktionalität. Letztere kann man immer noch verbessern. Schnittstellenänderungen sind kritisch. - Andererseits sind Schnittstellenänderungen auch verträglich, wenn sie formell adaptiert werden können.

Ein shared-Repository in bazaar scheint die Lösung zu bieten, aus einem recht großen Quellenumfang für verschiedene Komponenten verschiedene Quellen herauslösen zu können. Die Komponenten haben selbe gemeinsame Quellen, ggf. in verschiedenen Revisionen, die aber immer abgeglichen werden können sollten. Die Komponenten sind dann Basis für ein Produkt. Komponenten existieren in Form von libs oder jars in Java und können eigenständig getestet werden:

Quellen Komponenten Produkte
viele ===> weniger ===> aus Komponenten
verschiedene überschaubar und Produkt-spezial-Quellen
gebaut.

Wie funktioniert shared-Repository als zentraler Bezug - bin beim testen. (Hartmut)
==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.

Bazaar-Notes

JcHartmut — Wed, 23 Feb 2011 07:55:59 GMT

JcHartmut: Chapter Archivieren von Executables

@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

==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 [[https://bitbucket.org/jchartmut/cruntimejavalike 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.

Bazaar-Notes

JcHartmut — Mon, 21 Feb 2011 12:40:57 GMT

JcHartmut:

@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

==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 [[https://bitbucket.org/jchartmut/cruntimejavalike 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.

==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.

Bazaar-Notes

JcHartmut — Mon, 21 Feb 2011 12:35:35 GMT

JcHartmut: Created page with '@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 ==Kurzer Abriss, Arbeit mit MKSSI, git…'

@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

==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 [[!https://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.

==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.

Main Page

JcHartmut — Mon, 21 Feb 2011 12:31:45 GMT

JcHartmut:

Main Page

JcHartmut — Mon, 21 Feb 2011 07:22:51 GMT

JcHartmut:

Os types def

JcHartmut — Sun, 20 Feb 2011 09:15:39 GMT

JcHartmut: replace ,,text,, by <tt>text</tt>. ,,-designation is not wiki-style. TODO continue this work

==CRuntimeJavalike==
@ident=OSAL
.
===os_types_def.h===
@ident=os_types_def
.
====The necessity of a common basic header====
@ident=necessity

C-Sources are used and should be used in several projects and environments in unchanged form. But often there are incompatibilities especially while using user-defined types for fixed-with integer types (for example INT32) or other language-special (not application-special) details. Another problem are some incompatibilities between C++- and C-language. Often sources should be deployed in C-environments but should be reused in C++ too.

'''Prevent "#ifdef MyPlatform" in applications'''

The conditional compilation is a often-used construct to avoid incompatibilities. For example a sequence of inline-assembling for the target-platform is fenced and replaced by a proper expression for a simulation environment. But in re-used sources such project- and platform-specific conditionals causes a distension of code for all possibilities. Such a source-code isn't able to read far. The source-code should be changed, a new revision should created, only because a next platform-project-condition is incompatible with the current conditionals.

The better way to do is: Using of a macro in the common sources, defining the macro in a substantial platform-project-specific header and include that header.

'''Usage of a platform- or application-specific headers in more as one appearances in several directories'''

An unchanged re-used header- or C-file includes a header by name. The content of the included header should depend on the target platform etc. It is possible to have more as one header with the same file-name, but located in several directories. The platform is associated in any case either with the specific compiler or with specific make files. In the make-file or as command-line-options for the compiler, the include-path is specified. The include-path should refer to that proper directories, where the correct platform-depending header is located. In this kind commonly written sources are compiled with platform-depending properties. That is the philosopher's stone.

One of this platform-depending header is the <os_types_def.h>. It contains only basic definitions to adapt the operation system basic-features, the special compiler features for the platform and the basicly hardware features for the commonly reuse-able sources.

It is necessary to define which macros are defined in this <os_types_def.h> header. The user should be sure about the use-able macros. But the responsibility to the realization is taken in the specific header.

====Content of os_types_def.h====
@ident=content
.

=====Enhanced common types=====

The C-language-standard doesn't define all necessities of types. Independing of the used compiler and options (C/C++), the following types should be present for usage:

* <tt>bool true false</tt>: The boolean-type and its constants are defined well in C++. It is a internally representation of values for true and false. In C-applications this type and its values should be able to use in the same meaning. The ,,bool,,-type should be presented as an ,,int,, in C often. The value for <tt>false</tt> is <tt>0</tt> commonly. The <tt>true</tt>-value have to be the same as the presentation of a result of comparison for the current compiler. Usual a ,,!false,, presents the true-value correctly.

* <tt>int8_t int16_t int32_t int64_t uint8_t uint16_t uint64_t </tt> This are the identifiers of the fixed-width integer types which are defined in the C99-Standard. If the compiler supports C99, this definition are not necessary. In all other cases the C99-standard-types should be supported and therefore defined in the os_types_def.h header.

* ,,int8 int16 int32 int64 uint8 uint16 uint64 ,, This are the adequate identifiers of the fixed-width integer types, better able to read, usual in using, but not standardized.

* ,,UINT32,, etc.: Often adequate identifiers for the fixed.width integer are usual in use. It isn't a incompatibility to do so because the compiler understands the well-defined types as the same ones. If such user types are usual used, it should be defined in the <os_types_def.h> too. That allows to combine user-headers with all the usual fixed-width integer types without restrictions and incompatibility, if a compilation unit includes <os_types_def.h>. If the compilation unit doesn't include <os_types_def.h> but instead another header in the users space, where that types are defined, it isn't a problem. We assume, that ,,UINT32,, means a type which represents a integer value as 32 bit unsigned.

* ,,bool8 bool16,,: That both type definitions can be used in the user's application especially in struct-definition to define fixed-width boolean variables. Usual boolean values are stored as ,,int,, internally. But the ,,int,, type may have 16 or 32 bit. Therefore a ,,bool,,-Type should not be used in struct-definitions, which are used for data-interchanging. Instead, either ,,bool8,, or ,,bool16,, should be used there. Remark, a boolean value can be stored in 1 bit of a bitfield. But the bitfield should be declared as ,,int16,, ,,int32,, or adequate too.

* ,,char8 char16,, A ,,char,,-type is a byte often, but not guaranteed. A ,,char8,, is a byte guaranteed. If data for interchanging are declared in a struct, the ,,char8,,-type should be used. The ,,char16,,-type presents a character in 16 bits. Usual it is UTF16-encoding. This problem is resolved often with os-special types like ,,WCHAR,, etc. But all of this definitions are specials for some compiler platforms. Follow this commonly notification! The platform-specific ,,WCHAR,, etc. are left compatible with proper definitions. In the user sources only that platform-independent types should be used.

All types should be defined using a #define-statement, not using a ,,typedef,,. The reason is: Sometimes (especially for the operation-system-adaption layer) other header-files should be included, which defines the same identifier in a adequate way (compatible for usage in compiling) but incompatible while compiling the definitions itself. If the first-included <os_types_def.h> defines the types with ,,#define,,, an ,,#undef,, statement can be written before including the other necessary header-files. But ff a ,,typedef,, is used in <os_types_def.h>, the difference can only be resolved by changing the other headerfiles (remove the unecessary definitions). But the other included headerfiles are originals, which should not be changed often. Typical it may be necessary to write:

#include <os_types_def.h>
#include "someHeadersOfUser" //using definition of os_types_def.h
#undef int32
#undef uint32
#undef int16
#undef uint16
#include <specialPlatformHeader.h> //defines this types in another way but compatible
...implementation using the platformheader.h
...and the someHeadersOfUser including os_types_def.h-properties

This construct is not typical for the application-part of the software. The application parts should not depend on special platform headers. But it is typical for the os-adaption layer and for drivers, which have to be use the <specialPlatformHeader.h>.

=====Notification of used compiler and platform=====

Two defined labels allows conditional compiling in user-sources. The conditional compiling is not recommended. But if it is necessary or desired, it should be done in a unified schema. The defines are platform- and maybe project-depending. They should be queried only in a positive way (#ifdef) not negative (#ifndef). For usage on Windows with Visual Studio 6, the labels are named:

#define __OS_IS_WINDOWS__
#define __COMPILER_IS_MSC6__

Using that both labels, a special user routine can query for example:

#ifdef __OS_IS_WINDOWS__
//some statements for simulation ....
#endif

The distinction between os- and compiler label is: Usual the os-platform should be query. Only in special cases the compiler may be query, maybe for specific examination of errors etc.

That labels '''should not be used''' to force conditional compilation '''for commonly problems''' for example little/big endian, alignment requests etc.

=====pragmas to prevent warnings=====

In generally, any warning may be a hint to an error. But some warnings are ignorable. If such warnings are switched off, the critical warnings are visible better.

Warnings can be switched off individually by pragmas. The commonly valid pragmas to disable uncritical warnings should be included in the os_types_def.h. But only commonly and uncritical! The os_types_def.h can be adapted individually. In this case an individual setting of warning-pragma for a C-compiling project is possible.

The following example shows some warnings, which are switch off for the microsoft-visual-studio-compiler:

#pragma warning(disable:4100) //unused argument
#pragma warning(disable:4127) //conditional expression is constant
#pragma warning(disable:4214) //nonstandard extension used : bit field types other than int
#pragma warning(disable:4189) //local variable is initialized but not referenced
#pragma warning(disable:4201) //nonstandard extension used : nameless struct/union

=====Bit width and endian for the target processor=====

* ,,OSAL_BIGENDIAN,,: If this label is defined, the processor is a big-endian type. Some conditional compilation test this label to produce the correct access sequence. At user (high-) -level the big/little endian property should not be regarded. Only system routines should distinguish.

* ,,OSAL_LITTLEENDIAN,,: It is the opposite label for little endian.

* ,,OSAL_MEMWORDBOUND,,: This label should be defined, if the processor can't expand a variable over memory-word-bounds. For example if the processor is a 32-bit type, and a 32-bit-value is addressed by a odd memory address. In this case the value is located in 2 memory-words, One word contain in some bits the lo-value, the second word contains the high-bits. For a X86-architecture this isn't a problem, because that processor architecture supports the composition of the variable from any bytes in memory. But some processors have a problem with such constellations. The compiler itself prevent a splitting of variables usual by inserting fill-bytes (alignment-problem). But if a data stream comes with memory-bound-split values, an address calculation followed by a pointer casting and access (,,*(int32*)(calculatedAddress),,) causes errors. Then only more as one access to the memory and the composition of the value can help. This should be done by lo-level routines maybe in the users space too. For this routines, this label is used to control the code. The code of the routines can be written platform-independent then.

* ,,MemUnit,,: The MemUnit is a type which presents 1 word in memory. Most of the processors addresses the memory in bytes. Then this identifier should be defined as

#define MemUnit char

That is usual but not valid in any case. Some processor architectures are oriented to full-integer and float numerical information and saving hardware-effort for the memory access. Therefore they address the memory in 32-bit-words for example. In that case character values are not presented effective, but this may not be a problem. But the MemUnit is a int then:

#define MemUnit int

The user can use a ,,MemUnit*,, pointer for address calculations. Mostly a ,,char*,, is used instead in user-sources, submitting that a memory-word is a byte. But that is wrong in some cases.

* ,,BYTE_IN_MemUnit,,: A constant which describes how many bytes (not address-steps) are contained in a MemUnit (1 address-step). Usual it is defined as

#define BYTE_IN_MemUnit 1

But in the case of an abbreviated MemUnit the number of bytes per MemUnit may be 2 or 4. A Byte is 8 bit always. This constant is necessary to calculate space while interchanging of data for example via a Dual-Port-RAM, where a processor with another memory address-mechanism is the partner.

* ,,intPTR,,: defines a integer type, that can contain an address. It allows to store a memory address (a pointer to data) and handle (transfer) it as integer. The address calculation inside the processor space is the same as calculation with a ,,MemUnit*,,, but for calculation of addresses for another processor, the usage of ,,MemUnit*,, fails. The intPtr should present the usual used addressing mode. For a 16-bit-Processor with a more-width address space (more than 64 k words) it may be a simple int, including 16 bit. That is okay, if the free memory space for data is only located in a 64-k-range, all other memory spaces are for code, file system etc. But if the user-useable space is greater than 64k, the ,,intPTR,, should be defined for example as ,,int32,,.

For 32-bit-architectures it may be possible that an address consists of a 32-bit-address and an additional segment information. In that case a ,,intPTR,, may need to contain the segment too, it means it needs more than 32 bit. But in most of cases the address can be stored in 32 bit. In that kind it may be possible that a address will be condensed to 32 bit by truncation of (unused) address bits. Special operation are possible to do that. Then the ,,intPTR,, should present the condensed address for commonly usage.

=====OS_PtrValue=====

This structure is used to hold a pointer and an associated integer value to return it per value. It should be organized in a kind, that forces the usage of registers for the returned values. Normally, struct data, which are returned per value are copied from the stack in another stack location while execution the return machine instructions, after them they may be copied a second time into its destination struct-variable if the return-value is assigned to any one. The usage of register is much more effective. Because the usage of register may depend on some compiler specialities, the definition of this base struct is organized in this header. Frequently the definition of this struct is equal like shown in the example. But sometimes special constructs may be necessary.

The struct is defined as (pattern, frequently form)

typedef struct OS_PtrValue_t
{ char* ptr__;
int32 value__;
}OS_PtrValue;

The pointer may be a ,,void*,, in theory, but a char* allows to visit a referenced string while debugging. It may be opportune too to write

typedef struct OS_PtrValue_t
{ union{ char* c; int32Array* a;} ptr__;
int32 value__;
}OS_PtrValue;

to see a int-array while debugging. - It may be able to adjust, which int-type is stored and in which form the pointer is stored (segmentation? see ,,intPTR,,). Especially for simple 16-bit-Processors a proper definition should be find out.

There are defined some macros to access values and build constans:

* ,,CONST_OS_PtrValue(PTR, VAL),, This is a macro to build a constant expression to initialize, usual defined with ,,{ (char*) PTR, (int32)VAL},,.

* ,,value_OS_PtrValue(THIS),,: Gets the value, usual ,,((THIS).value__),,

* ,,PTR_OS_PtrValue(THIS, TYPE),,: Gets the pointer in form of the given type. TYPE is the base type, not the pointer (without ,,*,,), usual ,,((TYPE*)(THIS).ptr__),,

* ,,set_OS_PtrValue(THIS, PTR, INT),,: Sets all values, returns nothing (not able to use in expressions), usual ,,{ (THIS).ptr__ = (char*)(PTR); (THIS).value__ = (INT); },,

//NOTE: use a local variable to prevent twice call if SRC is a complex expression.
* ,,copy_OS_PtrValue(THIS, SRC),,: copy another OS_PtrValue into it. It is more simple as getting values from source and calling the set-macro. Hint: The SRC have to be accessed only one time, so a subroutine call can be written there. Usual: ,,{ OS_PtrValue const* src__ = &(SRC); (THIS).ptr__ = src__->ptr__; (THIS).value__ = src__->value__; },,

* ,,setValue_OS_PtrValue(THIS, INT),,: Macro to set a value, returns nothing (not able to use in expressions), usual ,,{ (THIS).value__ = (INT); },,

* ,,setPtr_OS_PtrValue(THIS, PTR),,: Macro to set a pointer, returns nothing (not able to use in expressions), usual ,, { (THIS).ptr__ = (char*)(PTR); },,.

====Content of os_types_def_common.h====
@ident=content

The header-file <os_types_def_common.h> should be included normally in <os_types_def.h> It contains definitions, which are valid and proper for all operation systems and compiler variants, but necessary respectively recommended at low level programming in C and C++. The OSAL-source package contains a version of this header-file for commonly usage. But it is possible for special requirements to adjusts nevertheless some properties, by including a changed variant of this file which is contained in the user's source-space. As a rule, the originally version should be used.

=====Specials for C++: extern "C" - usage=====

Generally, all sources should be use-able both for C and C++ compiling. It is an advantage that that programming languages are slightly compatible. The ,,extern "C",, -expression allows the usage of C-compiled library-parts in a C++-environment. But the ,,extern "C",, expression is understand only in C++-compiling. Usual headers of C-like-functions are encapsulated in

#ifdef __cplusplus__
extern "C" {
#endif
//...the definitions of this header
#ifdef __cplusplus__
} //extern "C"
#endif

This form allows the usage of the same header for C-compiling, without activating of this definition, and for C++-compiling. It is also proper to write a ,,extern "C",, to any ,,extern,, declaration. In some cases a ,,extern "C",,-declaration is helpfull in C++, but in C there shouldn't be a ,,extern,, instead. For example ,,typedef,, can be designated with ,,extern "C",, for the C++-compilation to designate the type as C-type. But it can't be replaced by a ,,extern,, in C.

The effect of ,,extern "C",, is: Labels for linking are build in the simply C-manner: Functions are designated with its simple name, usual with a prefix-,,_,,. The label doesn't depend on the function-signature (argument types). The same effect is taken for forward-declared variables. In opposite, in C++ the labels for linking are build implicitly with some additional type information, argument types for functions respectively methods, const or volatile information for variables etc. It is a advantage in C++, that the labels for linking contains some additional information about the element, not only the simple name. Therefore incompatibilities are able to detect in link time. But this advantage prevents the compatibility to C, and it is more difficult to correct errors, which are checked more strong than necessary in C++. Therfore a ,,extern "C",,-declaration in C++ makes sense in some cases.

To support a simple usage of ,,extern "C" in sources, which are used both for C and C++, the following macros are declared:

* ,,extern_C,,: This macro is defined for C++-compiling as ,,extern "C",, and for C-compiling as ,,extern,,. It designates ,,extern,, declarations especially for variables and static struct-incarnations.

* ,,C_TYPE,,: This macro is defined for C++-compiling as ,,extern "C",, but it is left empty for C-compilations. It should be used before a ,,typedef,, definition, especially for function-pointers, but also for the definition of struct-types.

* ,,extern_C_BLOCK_ _END_extern_C_BLOCK,,: This macros are defined as ,,extern "C" {,, and ,,},, for C++-compilation and left empty for C-compilation. It allows to write C-manner-definitions of a whole header (-block) in form

#include <dependHeaders.h>
extern_C_BLOCK_

some_definitions

_END_extern_C_BLOCK

====Which content should not contain in os_types_def.h====
@ident=noContent

Because the <os_types_def.h> is included in any C-file, some definitions which are used as basics for an application are inclined to find entrance in this file. But the effect or disadvantage is: The <os_types_def.h> is not more a file for the platform and compiler but for the application. It contains to much different thinks. Therefore a re-using for other applications with the adequate platform is aggravated. Therefore:

* Application-specific thinks shouldn't contain in this file. For example:
**Number of available ports and IP-addresses for Ehernet-Communication: This is a theme for the Ethernet-driver!
**Special hardware equipment properties: Theme for the special drivers!

* Commonly definitions which has not a reference to the platform shouldn't contain, for example:
** Definition of Pi (3.1415926...), it should contain in a <math..> header.

* The CRuntimeJavalike-platform-sources contain some definitions which are depending on the choice C/C++, the usage of 32-bit-integer for String-Length, modi of memory allocations etc. This thinks are defined in another header <fw_Platform_conventions.h> respectively <platformJc.h>. It is possible to build several appearances of CRuntimeJavalike-machinecode for the same base os/hardware-platform, therefore with the same <os_types_def.h>. On the other hand several os/hardware-platforms can use the same <platformJc.h> to defined adequate properties for Jc-appearances, but with different <os_types_def.h>-basic definitions. Therefore both headerfiles are separated together.

Help:Editing

JcHartmut — Sun, 20 Feb 2011 09:12:29 GMT

JcHartmut: Created page with 'see http://editthis.info/wiki/Help:Editing editthis.info/wiki/Help:Editing.'

see [[http://editthis.info/wiki/Help:Editing editthis.info/wiki/Help:Editing]].

Os types def

JcHartmut — Sun, 20 Feb 2011 08:38:48 GMT

JcHartmut: Created page with '==CRuntimeJavalike== @ident=OSAL . ===os_types_def.h=== @ident=os_types_def . ====The necessity of a common basic header==== @ident=necessity C-Sources are used and should be u…'

==CRuntimeJavalike==
@ident=OSAL
.
===os_types_def.h===
@ident=os_types_def
.
====The necessity of a common basic header====
@ident=necessity

C-Sources are used and should be used in several projects and environments in unchanged form. But often there are incompatibilities especially while using user-defined types for fixed-with integer types (for example INT32) or other language-special (not application-special) details. Another problem are some incompatibilities between C++- and C-language. Often sources should be deployed in C-environments but should be reused in C++ too.

'''Prevent "#ifdef MyPlatform" in applications'''

The conditional compilation is a often-used construct to avoid incompatibilities. For example a sequence of inline-assembling for the target-platform is fenced and replaced by a proper expression for a simulation environment. But in re-used sources such project- and platform-specific conditionals causes a distension of code for all possibilities. Such a source-code isn't able to read far. The source-code should be changed, a new revision should created, only because a next platform-project-condition is incompatible with the current conditionals.

The better way to do is: Using of a macro in the common sources, defining the macro in a substantial platform-project-specific header and include that header.

'''Usage of a platform- or application-specific headers in more as one appearances in several directories'''

An unchanged re-used header- or C-file includes a header by name. The content of the included header should depend on the target platform etc. It is possible to have more as one header with the same file-name, but located in several directories. The platform is associated in any case either with the specific compiler or with specific make files. In the make-file or as command-line-options for the compiler, the include-path is specified. The include-path should refer to that proper directories, where the correct platform-depending header is located. In this kind commonly written sources are compiled with platform-depending properties. That is the philosopher's stone.

One of this platform-depending header is the <os_types_def.h>. It contains only basic definitions to adapt the operation system basic-features, the special compiler features for the platform and the basicly hardware features for the commonly reuse-able sources.

It is necessary to define which macros are defined in this <os_types_def.h> header. The user should be sure about the use-able macros. But the responsibility to the realization is taken in the specific header.

====Content of os_types_def.h====
@ident=content
.

=====Enhanced common types=====

The C-language-standard doesn't define all necessities of types. Independing of the used compiler and options (C/C++), the following types should be present for usage:

* ,,bool true false,,: The boolean-type and its constants are defined well in C++. It is a internally representation of values for true and false. In C-applications this type and its values should be able to use in the same meaning. The ,,bool,,-type should be presented as an ,,int,, in C often. The value for ,,false,, is ,,0,, commonly. The ,,true,,-value have to be the same as the presentation of a result of comparison for the current compiler. Usual a ,,!false,, presents the true-value correctly.

* ,,int8_t int16_t int32_t int64_t uint8_t uint16_t uint64_t ,, This are the identifiers of the fixed-width integer types which are defined in the C99-Standard. If the compiler supports C99, this definition are not necessary. In all other cases the C99-standard-types should be supported and therefore defined in the os_types_def.h header.

* ,,int8 int16 int32 int64 uint8 uint16 uint64 ,, This are the adequate identifiers of the fixed-width integer types, better able to read, usual in using, but not standardized.

* ,,UINT32,, etc.: Often adequate identifiers for the fixed.width integer are usual in use. It isn't a incompatibility to do so because the compiler understands the well-defined types as the same ones. If such user types are usual used, it should be defined in the <os_types_def.h> too. That allows to combine user-headers with all the usual fixed-width integer types without restrictions and incompatibility, if a compilation unit includes <os_types_def.h>. If the compilation unit doesn't include <os_types_def.h> but instead another header in the users space, where that types are defined, it isn't a problem. We assume, that ,,UINT32,, means a type which represents a integer value as 32 bit unsigned.

* ,,bool8 bool16,,: That both type definitions can be used in the user's application especially in struct-definition to define fixed-width boolean variables. Usual boolean values are stored as ,,int,, internally. But the ,,int,, type may have 16 or 32 bit. Therefore a ,,bool,,-Type should not be used in struct-definitions, which are used for data-interchanging. Instead, either ,,bool8,, or ,,bool16,, should be used there. Remark, a boolean value can be stored in 1 bit of a bitfield. But the bitfield should be declared as ,,int16,, ,,int32,, or adequate too.

* ,,char8 char16,, A ,,char,,-type is a byte often, but not guaranteed. A ,,char8,, is a byte guaranteed. If data for interchanging are declared in a struct, the ,,char8,,-type should be used. The ,,char16,,-type presents a character in 16 bits. Usual it is UTF16-encoding. This problem is resolved often with os-special types like ,,WCHAR,, etc. But all of this definitions are specials for some compiler platforms. Follow this commonly notification! The platform-specific ,,WCHAR,, etc. are left compatible with proper definitions. In the user sources only that platform-independent types should be used.

All types should be defined using a #define-statement, not using a ,,typedef,,. The reason is: Sometimes (especially for the operation-system-adaption layer) other header-files should be included, which defines the same identifier in a adequate way (compatible for usage in compiling) but incompatible while compiling the definitions itself. If the first-included <os_types_def.h> defines the types with ,,#define,,, an ,,#undef,, statement can be written before including the other necessary header-files. But ff a ,,typedef,, is used in <os_types_def.h>, the difference can only be resolved by changing the other headerfiles (remove the unecessary definitions). But the other included headerfiles are originals, which should not be changed often. Typical it may be necessary to write:

#include <os_types_def.h>
#include "someHeadersOfUser" //using definition of os_types_def.h
#undef int32
#undef uint32
#undef int16
#undef uint16
#include <specialPlatformHeader.h> //defines this types in another way but compatible
...implementation using the platformheader.h
...and the someHeadersOfUser including os_types_def.h-properties

This construct is not typical for the application-part of the software. The application parts should not depend on special platform headers. But it is typical for the os-adaption layer and for drivers, which have to be use the <specialPlatformHeader.h>.

=====Notification of used compiler and platform=====

Two defined labels allows conditional compiling in user-sources. The conditional compiling is not recommended. But if it is necessary or desired, it should be done in a unified schema. The defines are platform- and maybe project-depending. They should be queried only in a positive way (#ifdef) not negative (#ifndef). For usage on Windows with Visual Studio 6, the labels are named:

#define __OS_IS_WINDOWS__
#define __COMPILER_IS_MSC6__

Using that both labels, a special user routine can query for example:

#ifdef __OS_IS_WINDOWS__
//some statements for simulation ....
#endif

The distinction between os- and compiler label is: Usual the os-platform should be query. Only in special cases the compiler may be query, maybe for specific examination of errors etc.

That labels '''should not be used''' to force conditional compilation '''for commonly problems''' for example little/big endian, alignment requests etc.

=====pragmas to prevent warnings=====

In generally, any warning may be a hint to an error. But some warnings are ignorable. If such warnings are switched off, the critical warnings are visible better.

Warnings can be switched off individually by pragmas. The commonly valid pragmas to disable uncritical warnings should be included in the os_types_def.h. But only commonly and uncritical! The os_types_def.h can be adapted individually. In this case an individual setting of warning-pragma for a C-compiling project is possible.

The following example shows some warnings, which are switch off for the microsoft-visual-studio-compiler:

#pragma warning(disable:4100) //unused argument
#pragma warning(disable:4127) //conditional expression is constant
#pragma warning(disable:4214) //nonstandard extension used : bit field types other than int
#pragma warning(disable:4189) //local variable is initialized but not referenced
#pragma warning(disable:4201) //nonstandard extension used : nameless struct/union

=====Bit width and endian for the target processor=====

* ,,OSAL_BIGENDIAN,,: If this label is defined, the processor is a big-endian type. Some conditional compilation test this label to produce the correct access sequence. At user (high-) -level the big/little endian property should not be regarded. Only system routines should distinguish.

* ,,OSAL_LITTLEENDIAN,,: It is the opposite label for little endian.

* ,,OSAL_MEMWORDBOUND,,: This label should be defined, if the processor can't expand a variable over memory-word-bounds. For example if the processor is a 32-bit type, and a 32-bit-value is addressed by a odd memory address. In this case the value is located in 2 memory-words, One word contain in some bits the lo-value, the second word contains the high-bits. For a X86-architecture this isn't a problem, because that processor architecture supports the composition of the variable from any bytes in memory. But some processors have a problem with such constellations. The compiler itself prevent a splitting of variables usual by inserting fill-bytes (alignment-problem). But if a data stream comes with memory-bound-split values, an address calculation followed by a pointer casting and access (,,*(int32*)(calculatedAddress),,) causes errors. Then only more as one access to the memory and the composition of the value can help. This should be done by lo-level routines maybe in the users space too. For this routines, this label is used to control the code. The code of the routines can be written platform-independent then.

* ,,MemUnit,,: The MemUnit is a type which presents 1 word in memory. Most of the processors addresses the memory in bytes. Then this identifier should be defined as

#define MemUnit char

That is usual but not valid in any case. Some processor architectures are oriented to full-integer and float numerical information and saving hardware-effort for the memory access. Therefore they address the memory in 32-bit-words for example. In that case character values are not presented effective, but this may not be a problem. But the MemUnit is a int then:

#define MemUnit int

The user can use a ,,MemUnit*,, pointer for address calculations. Mostly a ,,char*,, is used instead in user-sources, submitting that a memory-word is a byte. But that is wrong in some cases.

* ,,BYTE_IN_MemUnit,,: A constant which describes how many bytes (not address-steps) are contained in a MemUnit (1 address-step). Usual it is defined as

#define BYTE_IN_MemUnit 1

But in the case of an abbreviated MemUnit the number of bytes per MemUnit may be 2 or 4. A Byte is 8 bit always. This constant is necessary to calculate space while interchanging of data for example via a Dual-Port-RAM, where a processor with another memory address-mechanism is the partner.

* ,,intPTR,,: defines a integer type, that can contain an address. It allows to store a memory address (a pointer to data) and handle (transfer) it as integer. The address calculation inside the processor space is the same as calculation with a ,,MemUnit*,,, but for calculation of addresses for another processor, the usage of ,,MemUnit*,, fails. The intPtr should present the usual used addressing mode. For a 16-bit-Processor with a more-width address space (more than 64 k words) it may be a simple int, including 16 bit. That is okay, if the free memory space for data is only located in a 64-k-range, all other memory spaces are for code, file system etc. But if the user-useable space is greater than 64k, the ,,intPTR,, should be defined for example as ,,int32,,.

For 32-bit-architectures it may be possible that an address consists of a 32-bit-address and an additional segment information. In that case a ,,intPTR,, may need to contain the segment too, it means it needs more than 32 bit. But in most of cases the address can be stored in 32 bit. In that kind it may be possible that a address will be condensed to 32 bit by truncation of (unused) address bits. Special operation are possible to do that. Then the ,,intPTR,, should present the condensed address for commonly usage.

=====OS_PtrValue=====

This structure is used to hold a pointer and an associated integer value to return it per value. It should be organized in a kind, that forces the usage of registers for the returned values. Normally, struct data, which are returned per value are copied from the stack in another stack location while execution the return machine instructions, after them they may be copied a second time into its destination struct-variable if the return-value is assigned to any one. The usage of register is much more effective. Because the usage of register may depend on some compiler specialities, the definition of this base struct is organized in this header. Frequently the definition of this struct is equal like shown in the example. But sometimes special constructs may be necessary.

The struct is defined as (pattern, frequently form)

typedef struct OS_PtrValue_t
{ char* ptr__;
int32 value__;
}OS_PtrValue;

The pointer may be a ,,void*,, in theory, but a char* allows to visit a referenced string while debugging. It may be opportune too to write

typedef struct OS_PtrValue_t
{ union{ char* c; int32Array* a;} ptr__;
int32 value__;
}OS_PtrValue;

to see a int-array while debugging. - It may be able to adjust, which int-type is stored and in which form the pointer is stored (segmentation? see ,,intPTR,,). Especially for simple 16-bit-Processors a proper definition should be find out.

There are defined some macros to access values and build constans:

* ,,CONST_OS_PtrValue(PTR, VAL),, This is a macro to build a constant expression to initialize, usual defined with ,,{ (char*) PTR, (int32)VAL},,.

* ,,value_OS_PtrValue(THIS),,: Gets the value, usual ,,((THIS).value__),,

* ,,PTR_OS_PtrValue(THIS, TYPE),,: Gets the pointer in form of the given type. TYPE is the base type, not the pointer (without ,,*,,), usual ,,((TYPE*)(THIS).ptr__),,

* ,,set_OS_PtrValue(THIS, PTR, INT),,: Sets all values, returns nothing (not able to use in expressions), usual ,,{ (THIS).ptr__ = (char*)(PTR); (THIS).value__ = (INT); },,

//NOTE: use a local variable to prevent twice call if SRC is a complex expression.
* ,,copy_OS_PtrValue(THIS, SRC),,: copy another OS_PtrValue into it. It is more simple as getting values from source and calling the set-macro. Hint: The SRC have to be accessed only one time, so a subroutine call can be written there. Usual: ,,{ OS_PtrValue const* src__ = &(SRC); (THIS).ptr__ = src__->ptr__; (THIS).value__ = src__->value__; },,

* ,,setValue_OS_PtrValue(THIS, INT),,: Macro to set a value, returns nothing (not able to use in expressions), usual ,,{ (THIS).value__ = (INT); },,

* ,,setPtr_OS_PtrValue(THIS, PTR),,: Macro to set a pointer, returns nothing (not able to use in expressions), usual ,, { (THIS).ptr__ = (char*)(PTR); },,.

====Content of os_types_def_common.h====
@ident=content

The header-file <os_types_def_common.h> should be included normally in <os_types_def.h> It contains definitions, which are valid and proper for all operation systems and compiler variants, but necessary respectively recommended at low level programming in C and C++. The OSAL-source package contains a version of this header-file for commonly usage. But it is possible for special requirements to adjusts nevertheless some properties, by including a changed variant of this file which is contained in the user's source-space. As a rule, the originally version should be used.

=====Specials for C++: extern "C" - usage=====

Generally, all sources should be use-able both for C and C++ compiling. It is an advantage that that programming languages are slightly compatible. The ,,extern "C",, -expression allows the usage of C-compiled library-parts in a C++-environment. But the ,,extern "C",, expression is understand only in C++-compiling. Usual headers of C-like-functions are encapsulated in

#ifdef __cplusplus__
extern "C" {
#endif
//...the definitions of this header
#ifdef __cplusplus__
} //extern "C"
#endif

This form allows the usage of the same header for C-compiling, without activating of this definition, and for C++-compiling. It is also proper to write a ,,extern "C",, to any ,,extern,, declaration. In some cases a ,,extern "C",,-declaration is helpfull in C++, but in C there shouldn't be a ,,extern,, instead. For example ,,typedef,, can be designated with ,,extern "C",, for the C++-compilation to designate the type as C-type. But it can't be replaced by a ,,extern,, in C.

The effect of ,,extern "C",, is: Labels for linking are build in the simply C-manner: Functions are designated with its simple name, usual with a prefix-,,_,,. The label doesn't depend on the function-signature (argument types). The same effect is taken for forward-declared variables. In opposite, in C++ the labels for linking are build implicitly with some additional type information, argument types for functions respectively methods, const or volatile information for variables etc. It is a advantage in C++, that the labels for linking contains some additional information about the element, not only the simple name. Therefore incompatibilities are able to detect in link time. But this advantage prevents the compatibility to C, and it is more difficult to correct errors, which are checked more strong than necessary in C++. Therfore a ,,extern "C",,-declaration in C++ makes sense in some cases.

To support a simple usage of ,,extern "C" in sources, which are used both for C and C++, the following macros are declared:

* ,,extern_C,,: This macro is defined for C++-compiling as ,,extern "C",, and for C-compiling as ,,extern,,. It designates ,,extern,, declarations especially for variables and static struct-incarnations.

* ,,C_TYPE,,: This macro is defined for C++-compiling as ,,extern "C",, but it is left empty for C-compilations. It should be used before a ,,typedef,, definition, especially for function-pointers, but also for the definition of struct-types.

* ,,extern_C_BLOCK_ _END_extern_C_BLOCK,,: This macros are defined as ,,extern "C" {,, and ,,},, for C++-compilation and left empty for C-compilation. It allows to write C-manner-definitions of a whole header (-block) in form

#include <dependHeaders.h>
extern_C_BLOCK_

some_definitions

_END_extern_C_BLOCK

====Which content should not contain in os_types_def.h====
@ident=noContent

Because the <os_types_def.h> is included in any C-file, some definitions which are used as basics for an application are inclined to find entrance in this file. But the effect or disadvantage is: The <os_types_def.h> is not more a file for the platform and compiler but for the application. It contains to much different thinks. Therefore a re-using for other applications with the adequate platform is aggravated. Therefore:

* Application-specific thinks shouldn't contain in this file. For example:
**Number of available ports and IP-addresses for Ehernet-Communication: This is a theme for the Ethernet-driver!
**Special hardware equipment properties: Theme for the special drivers!

* Commonly definitions which has not a reference to the platform shouldn't contain, for example:
** Definition of Pi (3.1415926...), it should contain in a <math..> header.

* The CRuntimeJavalike-platform-sources contain some definitions which are depending on the choice C/C++, the usage of 32-bit-integer for String-Length, modi of memory allocations etc. This thinks are defined in another header <fw_Platform_conventions.h> respectively <platformJc.h>. It is possible to build several appearances of CRuntimeJavalike-machinecode for the same base os/hardware-platform, therefore with the same <os_types_def.h>. On the other hand several os/hardware-platforms can use the same <platformJc.h> to defined adequate properties for Jc-appearances, but with different <os_types_def.h>-basic definitions. Therefore both headerfiles are separated together.

Main Page

JcHartmut — Sun, 20 Feb 2011 08:36:59 GMT

JcHartmut: