Source-Version-Management-en

From Java4c

Contents

[edit] Source code management (SCM)

@ident=SCM-en

Links:

This size is the english version


[edit] 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.

[edit] 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.

[edit] 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.

[edit] 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.

[edit] 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


[edit] 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.
Retrieved from "http://editthis.info/Java4C/Source-Version-Management-en"
Personal tools