Multi-Bazaar-Components
From Java4c
Contents |
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 .bzr 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 .bzr-Archive, which does not contain the sources of the components. The .bzrignore-File should exclude the components sub directories.
The components sub directories have its own .bzr-Archive.
How to ensure the correct revision of the components
If the Application is resynchronized from a bazaar parent archive using bzr branch or bzr checkout 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 59 is the revision number. You can use a revision string too, see bzr help revisionspec. 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 bzrGetCmpn.bat.
@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.
