Source-Version-Management-de - Revision history

84.147.170.228: /* Überblick über die Anzahl Archive für die selbe Softwarekomponente ? etwas überarbeitet

2012-12-08T19:27:58Z

/* Überblick über die Anzahl Archive für die selbe Softwarekomponente ? etwas überarbeitet

← Older revision		Revision as of 19:27, 8 December 2012
Line 169:		Line 169:
	Die Kapitelüberschrift ist mit einem Fragezeichen versehen.		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.	+	Angenommen, es gibt etwa 10+x Stellen, an denen die selbe Softwarekomponente (gleiche Quellen) 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.	+	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. Allerdings gibt es dabei einen Mangel (Bazaar Version 2.3.0): Es werden zwar Differenzen des eigenen Archivs zum submit-Archiv angezeigt, also ein auf ein noch auszuführendes ''push'' hingewiesen. Es wird aber nicht ein neuer Stand im submit-Archiv angezeigt, der ''pull''-würdig wäre. Man erfährt also nicht dass man eigentlich gegenüber dem zentralen Archiv einen etwas älteren Stand hat. Aufbauend auf diesen arbeitet man dann los, um dann beim ''pull'' festzustellen, dass nun ein aufwändigeres ''merge'' ansteht.

-	~~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 ....	+	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.	+	Es kann passieren, das es in den Weiten der Festplatte Archive dem Entwickler nicht mehr bewusst ist, wo denn überall Archive stehen. 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.~~	+	'''Mit einem zentralen Archiv für einen Benutzer und eine Softwareversion geht es besser'''

-	~~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~~.	+	Die Arbeit mit einem zentralen Archiv gestaltet sich einfacher, wenn es eigentlich nur einen Hauptzweig gibt und Unterschiede vermieden werden sollen. Unterschiede entstehen eher unerwünscht bei Parallelarbeiten und sind möglichst schnell wieder abzustellen.

-	~~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.	+	Der Vorteil der dezentralen Archive liegt in der Dezentralisation bei mehreren Bearbeitern oder auf nicht immer im Netz verbundenen Computern eines Benutzers. Die totale Dezentralisation ist jedoch ggf. zuviel des Guten.

-	~~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~~.	+	Zweckdienlich kann es daher sein, für einen Bearbeiter auf einem PC nur ein Archiv zu halten. Voraussetzung dabei ist, dass alle Applikationen auch mit dem selben Softwarestand arbeiten wollen. Die Files sind nur deshalb mehrfach vorhanden, weil eine lokale Compilierung in der Appplikation stattfinden soll und die Archivierung der Files anderweitig eine Rolle spielt.

-	~~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.	+	Ich habe auf einem PC eine Entwicklungsumgebung (Eclipse für Java), in der in einem großen Projekt alle Quellen für alle Applikationen eingebunden sind. Damit ist es beispielsweise 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. Die Entwicklung an den Quellen wird also auf einem PC zentralisiert unabhänig von den Applikationen ausgeführt.
		+
		+	Jedoch gibt es bei mir für die einzelnen Applikationen verschiedene Stellen im Filesystem (Working areas). Die Applikationen müssen ihre Quellen in einem ''geschütztem Raum'' haben. Eine Änderung im Entwicklungsprojekt mit Blick auf Applikation X kann für Applikation Y zwar formell compilierfähig und grundsätzlich richtig sein, ist aber damit noch nicht wirklich getestet. Es kann sein, dass die Bearbeitung im Entwicklungsprojekt zeitlich stagniert und eine kleine Änderung und Auslieferung in Applikation Y dazwischenkommt. Mann kann sich nun keinesfalls auf den letzten Quellenstand beziehen sondern nur auf den gut getesteten Stand. Um nach kleinen Korrekturen einen neue Executable zu erzeugen, compiliere ich mit einem Batch-Aufruf. Das ist einfacher. Beim Batch-Aufruf werden die Files in der Working-Area der Applikation 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.
		+
		+	Da nun die Working area in Applikation Y kein eigenes Archiv hat, sind die Quellen in diesem Moment nicht archiviert und es entsteht auch kein Seitenzweig. Entweder kann mit einer Nacharbeitung ein Seitenzweig gebildet werden, wenn dies dauerhaft notwendig ist. Dann wird auf einem Parallelverzeichnis nun im nachhinein ein Bazaar-Archiv des notwendigen Standes aus dem zentralem Archiv gebildet und die Änderung dort committed. Der Seitenzweig lässt sich dann später wieder in den Hauptzweig mergen. Oft ist aber der Seitenzweig nicht notwendig. Die Änderungen in Applikation Y beziehen sich oftmals gar nicht auf die Quellen selbst sondern auf Zusatzfiles oder dergleichen. In der Nachbearbeitung kann dann statt dessen die Änderung direkt auf das zentrale Archiv überführt werden. Im zweiten Gang wird dann geprüft, ob der Hauptzweig vollständig funktionsfähig ist. Dazu braucht es etwas Testzeit. Damit entsteht gegebenenfalls zwar wieder eine Änderung in Applikation Y, die erneut ausgeliefert werden soll, nun aber wieder auf der Hauptversion basierend gegebenenfalls mit weiteren mittlerweile notwendigen Änderungen.
		+
		+	Hier wäre mal eine Skizze gut!!!
		+
		+	Der 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?		Wie kommt aber nun eine Detailänderung aus einer denzentralen Workingarea in das Archiv? Wie kommt der letzte Archivstand in die dezentrale Working-Area?

JcHartmut: /* Navigation */

2012-11-18T19:47:00Z

Navigation

← Older revision		Revision as of 19:47, 18 November 2012
Line 1:		Line 1:
	==Navigation==		==Navigation==
	* up: [[Main_Page]]		* 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		* down: TODO some examples and pattern

84.147.163.40: /* Mehrere Produkte aus einem Repository */ detail

2012-11-13T21:55:09Z

Mehrere Produkte aus einem Repository: detail

← Older revision		Revision as of 21:55, 13 November 2012
Line 370:		Line 370:


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

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

JcHartmut: link zu canonical

2012-11-10T11:09:44Z

link zu canonical

← Older revision		Revision as of 11:09, 10 November 2012
Line 6:		Line 6:
	@ident=SCM		@ident=SCM

-	Links:	+	Links local:
-	* [[Bazaar-guide]]: a guide to use Bazaar.	+	* [[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		This size is in german, because it is discussed in a german team. It will be presented in english in the future. TODO

JcHartmut: Archive nicht mehr gefunden?

2012-11-09T23:22:38Z

Archive nicht mehr gefunden?

← Older revision		Revision as of 23:22, 9 November 2012
Line 168:		Line 168:

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

JcHartmut: Navigation

2012-11-09T23:15:59Z

Navigation

← Older revision		Revision as of 23:15, 9 November 2012
Line 1:		Line 1:
		+	==Navigation==
		+	* up: [[Main_Page]]
		+	* down: TODO some examples and pattern
		+
	==Source code management (SCM)==		==Source code management (SCM)==
	@ident=SCM		@ident=SCM

JcHartmut: bzr_mvExpl.bat

2012-11-09T23:08:33Z

bzr_mvExpl.bat

← Older revision		Revision as of 23:08, 9 November 2012
Line 203:		Line 203:
	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!		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 Batch-File niederlegt:	+	Ich habe dazu folgende Befehlsfolge in einem zentralen Batch-File niederlegt:

-	.~~..TODO~~	+	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====		====Synchronisierung mehrerer Bearbeiter====

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

2012-11-09T21:48:09Z

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

← Older revision		Revision as of 21:48, 9 November 2012
Line 84:		Line 84:


-	===Mehrere Arbeitsverzeichnisse, mehrere SCM-Archive, Wiederverwendung===	+	==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.		Wird Software stark wiederverwendet, dann erscheinen die gleichen Quellfiles möglicherweise innerhalb der jeweiligen Applikationen selbst beim selben Bearbeiter mehrfach.
Line 96:		Line 96:
	Das SCM Bazaar unterstützt Seitenzweige mit automatisch unterstütztem merge.		Das SCM Bazaar unterstützt Seitenzweige mit automatisch unterstütztem merge.

-	Um ~~allerdings~~ Seitenzweige zu vermeiden, kann sich folgende Vorgehensweise als geeignet erweisen:	+	===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.		* Angenommen, eine Applikation A verwendet die Hauptversion 123.
Line 152:		Line 154:
	* Der Zyklus beginnt damit erneut, hoffentlich mit kleinen und kompatibel ausführbaren Änderungen, die für eine Beruhigung der Zyklen sorgt.		* 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 Batch-File niederlegt:
		+
		+	...TODO
		+
		+
		+	====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?==		==Source Content Management oder hart archivieren? Nur Quellen im SCM?==

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

2012-11-07T21:43:13Z

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

← Older revision		Revision as of 21:43, 7 November 2012
Line 154:		Line 154:


-	===Source Content Management oder hart archivieren? Nur Quellen im SCM?===	+	==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.		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.
Line 167:		Line 167:

	=>Schlussfolgerung: Für akutelle Softwareentwicklung jedenfalls ein Source-Integrity-Tool nutzen, Zippen nur zusätzlich.		=>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 ?===		===Quellen und Generate in einem Verzeichnis ?===

JcHartmut: Kompromiss - Arbeit mit Files und dem SCM

2012-11-07T21:28:30Z

Kompromiss - Arbeit mit Files und dem SCM

← Older revision		Revision as of 21:28, 7 November 2012
Line 68:		Line 68:
	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.		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===

-	==~~=Pflege~~ der ~~gleichen~~ Files ~~vom selben Bearbeiter an mehreren Stellen~~===	+	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.		Wird Software stark wiederverwendet, dann erscheinen die gleichen Quellfiles möglicherweise innerhalb der jeweiligen Applikationen selbst beim selben Bearbeiter mehrfach.