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.

Plugin List, which could be installed on repo

Server side

• https://launchpad.net/bzr-text-checker

  Currently we can check for new trailing whitespace, tabs, files not ending with a newline and long lines

• http://doc.bazaar.canonical.com/plugins/en/keywords-plugin.html

  Keywords like in CVS, which are expanded

• http://doc.bazaar.canonical.com/plugins/en/repo-push-plugin.html

  Pushes a complete Repo to another Repo, e.g. SF (when someone gives his private key...

• Hook, so that trunk commits are only allowed with --fixed commandline

Client side

• http://doc.bazaar.canonical.com/plugins/en/grep-plugin.html

  Helps searching inside the repo

• http://doc.bazaar.canonical.com/plugins/en/automv-plugin.html

  Add command bzr automv for detecting moves outside of bzr explorer

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

1. Checkout or update the trunk branch
2. Go to the directory of the trunk
3. Merge in the branch:

   bzr merge bzr+ssh://bazaar@bzr.openpetra.org:2208/openpetra/dev_id_whatever

4. Resolve conflicts
5. 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