[bt-devel] The future of development and DVCS

[Martin Gruner]

Eeli,

we have talked about this topic already.

My opinion is:
- SF SVN works well for us (except that it is slow, but I expect this to 
change at some point in future)
- all developers must be able to work easily with our VCS. Personally I'd 
prefer something with good Eclipse integration.
- it must be obvious that a change will bring benefits and does not disturb our 
development process.
- we need to have a thorough testing phase where we work together on a "dummy" 
repository to see how things work. Only if we then feel it is worth it we 
should switch.

If these criteria are met, I'm ready for a change. =) We might want to start 
with setting up a dummy git repository and see how we can get along with it 
(we shouldn't test several in parallel). A collection of _simple_ videos like 
the ones on github might be nice as a starter for dummies like me. 
For now, development should stay in SVN.

Regards, Martin

Am Freitag, 4. Dezember 2009 23:31:08 schrieb 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)
> 
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel
> 

-- 

Bauplan des Lebens - längst im Gen entdeckt!
Die Wissenschaft ist stolz: Sie hat's gecheckt.
Nun ist der Bauplan als Beweis beliebt,
dass es den Architekten gar nicht gibt.

Wolf Rahn