[GenABEL-dev] Some thoughts on migrating *ABEL from svn to a distributed version control system

[L.C. Karssen]

Dear all,

Lately I've been thinking about whether we should move the *ABEL sources
from subversion (SVN) to a distributed version control system (DVCS).
Examples of DVCSs are git, mercurial and bazaar. 

There are several reasons for moving the code to a DVCS, the ones that
triggered my to think about this are (not necessarily for *ABEL, but for
some of my other projects):
- I needed to drop work on one task and switch tracks to another one
without having to make commits with unfinished changes
- I wished I could just create branches to work on a feature or a bug
without worrying about the consequences to the main repo.
- I wanted to use version control while being offline.

Ref. [1] gives a nice discussion on why to use a DVCS. 

I think that even if we don't move to a DVCS, we should still
restructure our SVN layout. At the moment we don't make use of the
possibilities to make branches and tags. There is only one place in our
SVN repo and that's were all development goes to. from bug fixes to new
features. Ideally one should have those two separate: bug fixes in the
stable branch and new features in the development branch..

Basically with any DVCS we can setup a main branch (like our SVN repo
now) which will hold the 'official' *ABEL. Then, people can branch from
that and work on the features they want to implement. But they can also
quickly make a branch to fix a bug without disturbing their work on the
new feature. Whenever their work is finished they create a merge
request. Such a merge request is basically an e-mail with a patch
(created with a single command). The e-mail should be send to this list.
The patch can then be reviewed by the people on the list and finally the
person responsible for the main branch (the gatekeeper) decides whether
to integrate the patch into the main branch (whether as a fix of a
stable release or a new feature in the development branch is of course
open). 
In this way we have the freedom for everyone to work on sub-projects
while still having one main reference point (controlled by the
gatekeeper). This should also serve as a form of quality assurance. 
Ref.[3] contains more info on this model (and several others). Of course
different strategies are open to discussion.

For my own projects I've recently switched from using both RCS (yeah,
really old, but good for small local projects without collaboration) and
SVN to using bazaar [2]. I'm very happy with the DVCS way of working. 

There are other DVCSs as well, mainly git (e.g. used by the people who
develop the Linux kernel) and mercurial. I don't have experience with
either of these so I'd love to get comments from people that use them. 

The things I like about bazaar are:
- its user friendliness (also for people who are not programming for a
living (like myself)). Git seems to have a steeper learning curve
(although I didn't try it myself)
- Excellent documentation
(http://doc.bazaar.canonical.com/bzr.2.2/en/ ). The user guide is an
easy read.
- it has both checkouts and branches. Bazaar has a checkout command
which is the same as in Subversion.
- apart from the command line tool (bzr) there's a GUI for those who
want (Bazaar Explorer)

For use with *ABEL bazaar has the following advantages as well:
- Cross platform support, it's built on Python and runs great in
Windows, Mac, and Linux.
- Eclipse support

Refs.[4-5] are a few recent comparisons of git, mercurial and bazaar.
Ref.[6] is more biased.


Moving to a different way of doing version control is a major step and
shouldn't be undertaken lightly. We'd like to make such a decision with
full support of our developer community, so tell us about your
experiences or thoughts on this matter. 


Kind regards,

Lennart Karssen.


References:
[1]
http://weblog.masukomi.org/2008/06/27/why-you-should-use-a-distributed-version-control-system
[2] http://bazaar.canonical.com/en/
[3]
http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/using_gatekeepers.html
[4]
http://rails.brentsowers.com/2010/09/my-distributed-version-control-system.html
[5]
http://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/
[6]
http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html


-- 
-----------------------------------------------
L.C. Karssen
Erasmus MC
Department of Epidemiology
Room Ee2224

Postbus 2040
3000 CA Rotterdam
The Netherlands

phone: +31-10-7044217
fax: +31-10-7044657
email: l.karssen at erasmusmc.nl
GPG key ID: 0E1D39E3
-----------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.r-forge.r-project.org/pipermail/genabel-devel/attachments/20110104/02ad14a9/attachment.pgp>