[bt-devel] The future of development and DVCS
Gary Holmlund
gary.holmlund at gmail.com
Fri Dec 4 20:01:53 MST 2009
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
>
More information about the bt-devel
mailing list