View source for Other Source Code Versioning System than git

= Branching Strategy =
Typically you would generate one branch per feature or bug fix. To each feature or bug fix there is one entry in your bug tracker (e.g. Mantris) and they are named by convention:
[[File:FeatureBranch.png]]
You would create a branch and start working and checking in your changes. You should frequently rebase (sometimes called merge in) the branch by merging in the changes from the branch you have branched off. Before merging back you do a last rebase and document the test in the bug tracker. Now you would merge the changes to the branch, where you have branched off. This should be a "copy-merge": The version on the branch includes all changes you have done and all changes from the main branch. Because of this, the VCS should detect, that the files could be copied back to the main branch without change.

= Requirements =
* Easy branching
* Good merge support for rebasing
* Detection, if a merge is a "copy-merge".
* Good visualization of history:
** See the name of a branch
** See, where the branch branched off
** See, where the branch was rebased
** See, where the branch was merged out
* Possibility to lock a branch
* Concept, so that a mission agency could work with an own VCS, which gets the current information from the main VCS
* Concept for force policies:
** Branch naming convention
** Tag naming convention
** Who is allowed to commit to the master/default/release branch
** Force Bug-Id in the commit message for commits to master/default/release branch

= List of VCS supported by SourceForge =
* [[Git]]
* [[Mercurial]]
* [[Bazaar]]
* [[Subversion]]
* [[CVS]]

= Some Links =
* http://www.martinfowler.com/
* http://www.cmcrossroads.com/cgi-bin/cmwiki/view/CM/WhosWhoInSCM
* http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
* Continuous Integration:
** http://confluence.public.thoughtworks.org/display/CC/Understanding+the+alternatives+to+CruiseControl
** http://www.martinfowler.com/articles/continuousIntegration.html#MaintainASingleSourceRepository
* VCS Overview:
** http://www.python.org/dev/peps/pep-0374/ (Spring 2009)
**:Reasoning why Mercurial and not Bazaar:
*** https://lists.ubuntu.com/archives/bazaar/2009q1/055857.html
*** https://lists.ubuntu.com/archives/bazaar/2009q1/055872.html
*** https://lists.ubuntu.com/archives/bazaar/2009q1/055872.html 
* Branching:
** http://nvie.com/posts/a-successful-git-branching-model/ (With Git Push/Pull this is not working)
** http://www.infoq.com/articles/agile-version-control
** http://simpleprogrammer.com/2010/06/02/merge-in-merge-out/(Rebase before Merging)
* Dev-Process:
** http://simpleprogrammer.com/2009/12/14/kanbandwagon-kanban-vs-scrum/
** http://www.python.org/dev/workflow/ (Example of Issue tracking in Python)

= What others use =
** Git:
*** Linux Kernel
** Bazaar:
*** MySql, MariaSql
*** Squid
*** Emacs
*** Mailman
** Mercurial:
*** illumos (OpenSolaris Nachfolger)
** Subversion:
*** FreeBSD
*** Python
** CVS
*** NetBSD

= Recommendation =
Move away from 'Git'. Main problems, which are not shared with Bazaar and Mercurial:
* Does implicit operations like git commit -a on a merge without conflict
* Has many "features", with which you could change the repository later on changing history
* The version graph has not the information where a branch started, where it was rebased and where it was merged back.

Bazaar had performance (speed) problems in the past. This was preventing Python to move to Bazaar and they chose Mercurial instead. In the meantime, this should not be a problem anymore, but there are no good actual performance comparisons in the net.

Bazaar has the neat advantage of the supported workflow with a central server: Each commit will do the commit on the central server before committing locally. Additional it has the option to commit locally and push it later, if you are offline.
The committing on the central server before committing locally helps avoiding the typically more then one heads problem (Mercurial terminology).

'''The architecture team decided to use bazaar on an own server, so that we could implement server side hooks later on.'''
Main reason: The client could use as provided by bazaar without additional plugins for supporting a centralized development process.


= How to work with bazaar =

== Setup your environment ==

Install bazaar.

Set your E-Mail address:
 bzr whoami "John Doe <john.doe@gmail.com>"

Create a directory where you want to store all bazaar checkout you are using with openpetra, e.g. C:\openpetra\bzr
Go into this directory and create a shared repository for holding all branches you checkout:
 C:\openpetra\bzr>bzr init-repo --no-trees ./
 Shared repository (format: 2a)
 Location:
   shared repository: .
 C:\openpetra\bzr>

On windows set environment variable BZR_SSH for using plink.exe from putty instead of ssh. If plink is in the path, you could use
 BZR_SSH=plink
Otherwise you should set BZR_SSH with the absolut path to plink:
 BZR_SSH=c:\programs\putty\plink
''NOTE: if you path contains a space character, eg. C:\Program Files\PuTTY\plink: you need to replace the part of the path that contains the space character with the 8.3 (MS-DOS)-style name of that directory (e.g. C:\Progra~1\PuTTY\plink) to avoid strange errors when connecting to the Bazaar Server!
''

If you tortoisebzr is showing a strange language, then you selected perhaps German and you see a different language. Just remove the different languages except for en in %ProgramFiles%\Bazaar\locale\

== Get files ==

In our example we will use the URL bzr+ssh://bazaar@bzr.openpetra.org:2208/openpetra/ for the developer repository.
For anonymous access you could use the URL http://bzr.openpetra.org:8008/openpetra/ instead.

With the command
 bzr explorer bzr+ssh://bazaar@bzr.openpetra.org:2208/openpetra/
You could see the history of all active branches

Now you could checkout a branch. The master branch is called trunk (like in subversion) in the shared repo from above, e.g. C:\openpetra\bzr:
 bzr checkout bzr+ssh://bazaar@bzr.openpetra.org:2208/openpetra/trunk
If you want to checkout another branch, just exchange trunk with the branch name

== See changed files ==
 bzr status

== Graphical Interface ==

Call the explorer in directory of the branch you are interested in:
 bzr explorer ./


== Branches ==

See all branches in OpenPetra:
 bzr branches bzr+ssh://bazaar@bzr.openpetra.org:2208/openpetra/

Add a new branch (the directory, where the command is executed, is not relevant):
 bzr branch bzr+ssh://bazaar@bzr.openpetra.org:2208/openpetra/trunk bzr+ssh://bazaar@bzr.openpetra.org:2208/openpetra/dev_id_whatever
Afterwards you need to checkout it out with the command described above (Get files)

For info about your branch, execute in the directory of your checkout:
 bzr info

=== Rebase branch ===

For this commands you need to be in the directory, where the checkout files are in.

For the first rebase of the branch, you need to add the info, from where to merge:
 bzr merge bzr+ssh://bazaar@bzr.openpetra.org:2208/openpetra/trunk
This information you see on the operation
 bzr info

For the next rebase merges, following command is working:
 bzr merge

Checkin the changes:
 bzr commit

=== Update a branch with the newest info from remote ===
Needed for the getting the newest changes for trunk or for branches, where more then one person is working on:
 bzr update


=== Merge to trunk ===
# Checkout or update the trunk branch
# Go to the directory of the trunk
# Merge in the branch:
#:  bzr merge bzr+ssh://bazaar@bzr.openpetra.org:2208/openpetra/dev_id_whatever
# Resolve conflicts
# bzr commit

== Back out a commit ==

Backing out a commit is done by merging. First, you should identify the revision number, e.g. 284.
Then you are able to undo the commit by merging the difference between 284 and 283:
 bzr merge -r 284..283 ./
 bzr commit