Bazaar-Notes - Revision history

Admin: /* More as one Repository for one product */

Admin — Fri, 09 Sep 2011 08:25:36 GMT

More as one Repository for one product

← Older revision		Revision as of 08:25, 9 September 2011
Line 118:		Line 118:
	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.		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 ~~batchfile~~ should be ~~able to locate~~ in the PATH of the computer. It is a thing of installation, not a thing of the designated sources. It contains - for windows - and should be adapted to the concretely conditions at the PC-installation:	+	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		@echo off

Admin: /* Mehrere Repositories für ein Produkt */

Admin — Fri, 09 Sep 2011 08:22:47 GMT

Mehrere Repositories für ein Produkt

← Older revision		Revision as of 08:22, 9 September 2011
Line 88:		Line 88:
	* 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.		* 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~~==	+	==More as one Repository for one product==
	@ident=multiBzr		@ident=multiBzr

-	;~~Produkt aus mehreren Quell-Komponenten~~	+	;Products with more as one components.

-	:~~Produkt (Executable etc~~.~~) besteht aus Quellen aus mehreren Projekten (Komponenten).~~	+	: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.
-	~~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.~~	+	:Conclusion: Do not mix sources, separate it. Therefore any component needs its own bzr archive.
-	~~Jede Quell-Komponente wird in ihrem eigenem~~ .bzr~~-repository gepflegt~~.	+

-	;~~Quell~~-~~Komponenten befinden sich im Produkt-Sourcenbaum in jeweils bestimmten Unterverzeichnissen~~	+	;Sources of components should be located in a subdirectory of the product source tree. It is helpfull to use sub-directories to keep tidiness.

-	:~~Unterverzeichnisordnung ist zweckmäßig~~, ~~weil damit auch im Produkt-Verzeichnis ordnung herrscht~~.	+	: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.

-	:~~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~~.	+	:Conclusion: The .bzr repositiory of a component should be located in a sub directory of the product source tree.

-	: ~~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~~.	+	:The name of the sub directory should, but doesn't need be identical with the name of the component.

-	~~:Schlussfolgerung: Das .~~bzr~~-Repository der Quellen der Komponente sollte in dem Unterverzeichnis stehen.~~	+	;Getting of source tree of a component, getting its bzr archive

-	~~: 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~~.	+	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.

-	~~Das spricht insgesamt dafür~~, ~~ein Produkt aus mehreren Bazaar-Quell-Repositories zusammenzusetzen~~.	+	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 batchfile should be able to locate in the PATH of the computer. It is a thing of installation, not a thing of the designated sources. 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.

	==Mehrere Produkte aus einem Repository==		==Mehrere Produkte aus einem Repository==

Admin: /* Side branches */ Experience with image on foreign internet page

Admin — Sat, 06 Aug 2011 06:19:44 GMT

Side branches: Experience with image on foreign internet page

← Older revision		Revision as of 06:19, 6 August 2011
Line 221:		Line 221:
	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.		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.

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

	'''Now back to bazaar''':		'''Now back to bazaar''':

Admin: test image

Admin — Fri, 22 Jul 2011 20:54:36 GMT

test image

← Older revision		Revision as of 20:54, 22 July 2011
Line 221:		Line 221:
	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.		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.

-	[[~~Img~~:~~http://www.vishia.org/SwEng/pictures/~~git-side-branch-example.~~jpg~~\|example side branches in git]]	+	[[Image:git-side-branch-example.png\|example side branches in git]]

	'''Now back to bazaar''':		'''Now back to bazaar''':

Admin: /* Side branches */

Admin — Fri, 22 Jul 2011 20:42:14 GMT

Side branches

← Older revision		Revision as of 20:42, 22 July 2011
Line 180:		Line 180:

	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.		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.
		+
		+	[[Img:http://www.vishia.org/SwEng/pictures/git-side-branch-example.jpg\|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

Admin: side branches to commit changes for bugfixes, how to work

Admin — Fri, 15 Jul 2011 16:40:04 GMT

side branches to commit changes for bugfixes, how to work

← Older revision		Revision as of 16:40, 15 July 2011
Line 163:		Line 163:

	: Schlussfolgerung: Schnelle Änderungen ->Seitenzweig, Auflösen dessen, Änderung in Hauptzweig einfließen lassen und Adaption des Produktes auf Hautpzweig der Komponenten ausführen.		: 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.

84.147.181.165: /* Zentrale Ablage für Repositories */

84.147.181.165 — Thu, 31 Mar 2011 18:27:38 GMT

Zentrale Ablage für Repositories

← Older revision		Revision as of 18:27, 31 March 2011
Line 137:		Line 137:

	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.		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==		==Branches und dessen Auflösung==

194.138.39.61: Links on top of text, to fast navigation, Bazaar-guide

194.138.39.61 — Wed, 23 Feb 2011 15:41:36 GMT

Links on top of text, to fast navigation, Bazaar-guide

← Older revision		Revision as of 15:41, 23 February 2011
Line 1:		Line 1:
	@ident=Bazaar_notes		@ident=Bazaar_notes
		+
		+	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		This size is in german, because it is discussed in a german team. It will be presented in english in the future. TODO

JcHartmut: sharedReopositories

JcHartmut — Wed, 23 Feb 2011 08:10:01 GMT

sharedReopositories

← Older revision		Revision as of 08:10, 23 February 2011
Line 38:		Line 38:


-	==Source Content Management oder hart archivieren?==	+	==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 111:		Line 111:


-	==~~Verzeichnisstrukturen~~==	+	==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.

-	*~~Grundsätzlich~~ Quellen von ~~Produkten trennen~~	+	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==		==Zentrale Ablage für Repositories==
	@ident=centralRepos		@ident=centralRepos

JcHartmut: Chapter Archivieren von Executables

JcHartmut — Wed, 23 Feb 2011 07:55:59 GMT

Chapter Archivieren von Executables

← Older revision		Revision as of 07:55, 23 February 2011
Line 69:		Line 69:
	* Generierergebnisse neben dem Source-Baum 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==		==Mehrere Repositories für ein Produkt==