Source-Version-Management-en
From Java4c
Contents |
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
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.
[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.
