-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 5, 2007, at 1:58 PM, [EMAIL PROTECTED] wrote:
> amk> Tangentially related: > amk> At PyCon, there was general agreement that exposing a read- > only > amk> Bazaar/Mercurial/git/whatever version of the repository > wouldn't be > amk> too much effort, and might make things easier for external > people > amk> developing patches. > > I'm not much of a version control wonk. How would these help? > Can't the > folks who need such stuff do some sort of anonymous svn checkout? Part of the problem is that you want to be able to publish your changes in a form that's much more conducive to collaboration than diff files. An anonymous svn checkout can't effectively be published or shared and you don't want to hand out writable access to svn to everyone. With a dvcs like Bazaar/Mercurial, et all, control of writable branches is totally decentralized. Yes, there's always the blessed central branch(es) coming from python.org, but it's very easy for Joe Shmoe to create their own writable branches, make their changes, publish them as full-fledged branches, etc. I see adopting a dvcs as beneficial in a number of ways. First, it allows people to participate even without write access, as almost first class citizens. About the only thing they can't do is commit back to the blessed branches, but that doesn't stop them from sharing their branches exactly the way we do. Also, it gives core developers a better way to review and test other people's branches because you can just pull their branch and start using it. In fact you can even branch their branch and publish your own version as a "review branch". Depending on the specific dvcs chosen, there are lots of ways to share branches that are much more "live" than diff files. Finally, because branching is so cheap (even cheaper than with svn), a dvcs is great for us even if it doesn't get us more developers. It's so much nicer to have a vcs that understands merges natively, and can track them across branches, so it lets us create cheap little branches for little features. For example, I'm sitting on a checkout of the implementation for a new PEP we worked on at PyCon. I could create an svn branch for this work, but that's fairly heavyweight, / and/ it requires me to have access to the server (which I didn't have on the train from PyCon, and I screwed up my checkout because of that). With a dvcs, I could publish my changes in any number of ways and still just have this one little branch for this one little feature. Hope that makes sense! I haven't used a real dvcs for very long, but I'm starting to see the fundamental improvements to the development process that it makes possible. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRexrTXEjvBPtnXfVAQLXjwP/YKfdMy0QYzbIEWHOGgcAAAnIoVpdN7Vm yo2qYgFwE4hrTSCiKuA5QBqF8GfbFKUpPUlMhr1OiRzrR8VVLaJpDTyFzwaukndm DbFtB/wG9GAKAS0ExIQy2wNx1ddtIWbnvsFYAnpKPDpaEadhM9pHfafiuc9C9Rme XlGB2T3SMZw= =EBbc -----END PGP SIGNATURE----- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
