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

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

  In conjunction with kdiff3 for graphical merging

How to work with bazaar

see the articles

• How to work with bazaar on the command line
• How to work with bazaar through the GUI on Windows