[bt-devel] The future of development and DVCS

['Kang Sun']

Eeli, are you using git-svn now to save your local changes or to 
merge/ignore current commits?


* Eeli Kaikkonen <eekaikko at mail.student.oulu.fi> wrote on [2009/12/04 16:38]:
> 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)
> 
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel