[bt-devel] The future of development and DVCS

[Gregory Hellings]

Recently I've started using git in some of my own development of web  
work and thus far I seriously dislike it's work flow. It could be that  
I don't fully understand it's workflow yet, but I can't even properly  
push to my own original repository's master branch and deleting files  
on any branch does not effectively delete them on any other branches,  
even following the exact workflows in the official git manual.

Granted, the amount of commits I make is extremely minimal, but so far  
I love svn for every used I've had (except actual initial config) and  
have yet to see any real benefits of git (though there are great  
theorectical reasons!)

--Greg



On Dec 4, 2009, at 4:31 PM, Eeli Kaikkonen <eekaikko at mail.student.oulu.fi 
 > wrote:

> 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