[bt-devel] The future of development and DVCS

[Eeli Kaikkonen]

As some of you noticed in irc, our developer base has grown. If it still
grows, we have to change our ways of working. One critical part of
development process is the version control system. I have written about
this earlier, I was already planning moving to a DVCS, but sourceforge
services weren't good enough. Git was otherwise good, but the Windows
support of git was bad and it made it a non-option for us. Sf.net
didn't support bazaar advanced repository layouts or multiple
repositories per project. Hg I didn't bother to learn for some reason,
and multiple repos weren't supported then by sf.net.

Things have changed a bit. Bzr is still out of question because of poor
sf.net support. Multiple repositories are supported for git and hg. But
the most important change may be that git works nowadays quite well on
Windows.

Personally I have used git-svn with BibleTime code long time ago,
successfully. Recently I have tried bzr-svn, also successfully. Anyone
who knows bzr-svn can check my latest svn commits - they are made with
bzr-svn and it shows in the log, even the merges are included.

I'm convinced that using decentralized version control system would make
our work easier in the long run. I know very well there's a learning
curve and it's more difficult than with svn. However, it pays back. Many
many developers use a dvcs privately even though the central repository
is old centralized svn or even cvs. If you learn some good workflows
(local branching) it will make your own work easier and potentially
enhances the code quality, especially if you code more than just one
little thing at a time. And this can happen even if our central repo
stays the same and other's don't know what you're doing!

But the real benefit would be in communication and sharing, for which
dvcs's were invented. For example, each developer could add experimental
branches to our repo - or publish branches somewhere else than in our
sf.net service - and share their work in truly open way, "releasing
early, releasing often". Other developers could follow their work. When
a feature/fix/change would be ready, a developer could announce it and
ask for comments. Others could pull the branch and test it before it's
committed (merged) to the master/trunk branch. Merging is a first class
citizen in dvcs world, unlike in svn. That makes distributed and
experimental development easy.

What DVCS you know or like? What you would like us to use? Other
comments or questions or suggestions?

  Yours,
	Eeli Kaikkonen (Mr.), Oulu, Finland
	e-mail: eekaikko at mailx.studentx.oulux.fix (with no x)