Other Source Code Versioning System than git: Difference between revisions
(Created page with '= 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 a…') |
m (typo corrected) |
||
| Line 1: | Line 1: | ||
= Branching Strategy = | = 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: | 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: | [[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. | 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. | ||
Revision as of 17:02, 7 December 2010
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
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:
- VCS Overview:
- http://www.python.org/dev/peps/pep-0374/ (Spring 2009)
- Reasoning why Mercurial and not Bazaar:
- http://www.python.org/dev/peps/pep-0374/ (Spring 2009)
- 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
- Git:
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.