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: 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

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