[bt-devel] The future of development and DVCS

[Troy A. Griffitts]

Please know that the CrossWire server is available if it can be of use
for your development.  I'm not yet sold on git-- many of the new
features people point to as good scare me :)  But I'd love for another
project to go for it and be the Guinea Pig!

We have pretty heavy iron and a fat pipe on our server, but someone
would have to volunteer to admin the git services.

I've mentioned git over any other scm because I feel that greater than
exactly the best features, popularity and momentum is more valuable in
the oss world to make it familiar for the most number of developers.
And I doubt there are highly significant feature benefits of another
dvcs tool over git.

But I'm no expert, so please let me know if you disagree.

	-Troy.






On Fri, 2009-12-04 at 19:01 -0800, Gary Holmlund wrote:
> I tried using git-svn when you suggested it early this year. It was nice 
> to be able to check in locally frequently. But, the tools I found for 
> using it were not as nice as svn, so I quit using it. That is the only 
> DVCS experience that I have had.
> 
> I certainly would be interested in again if I can find good client tools.
> 
> SourceForge claims to support Bazaar. What about SF is bad with it?
> 
> Gary
> 
> 'Kang Sun' wrote:
> > [If anyone objects to top-posting, please say something]
> >
> > I'm in favor of a move to Bazaar as long as there is a gatekeeper (human  
> > or not) for the main branch.
> >
> > As for SF, if the bzr support is still bad, why not move a fork over to 
> > Launchpad?  Are reports of SF support of bzr still bad?
> >
> > * 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?
> >>
> >>     
> >
> > _______________________________________________
> > bt-devel mailing list
> > bt-devel at crosswire.org
> > http://www.crosswire.org/mailman/listinfo/bt-devel
> >   
> 
> 
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel