Categories
Posts in this category
- A shiny perl6.org site
- Creating an entry point for newcomers
- An offer for software developers: free IRC logging
- Sprixel, a 6 compiler powered by JavaScript
- Announcing try.rakudo.org, an interactive Perl 6 shell in your browser
- Another perl6.org iteration
- Blackjack and Perl 6
- Why I commit Crud to the Perl 6 Test Suite
- This Week's Contribution to Perl 6 Week 5: Implement Str.trans
- This Week's Contribution to Perl 6
- This Week's Contribution to Perl 6 Week 8: Implement $*ARGFILES for Rakudo
- This Week's Contribution to Perl 6 Week 6: Improve Book markup
- This Week's Contribution to Perl 6 Week 2: Fix up a test
- This Week's Contribution to Perl 6 Week 9: Implement Hash.pick for Rakudo
- This Week's Contribution to Perl 6 Week 11: Improve an error message for Hyper Operators
- This Week's Contribution to Perl 6 - Lottery Intermission
- This Week's Contribution to Perl 6 Week 3: Write supporting code for the MAIN sub
- This Week's Contribution to Perl 6 Week 1: A website for proto
- This Week's Contribution to Perl 6 Week 4: Implement :samecase for .subst
- This Week's Contribution to Perl 6 Week 10: Implement samespace for Rakudo
- This Week's Contribution to Perl 6 Week 7: Implement try.rakudo.org
- What is the "Cool" class in Perl 6?
- Report from the Perl 6 Hackathon in Copenhagen
- Custom operators in Rakudo
- A Perl 6 Date Module
- Defined Behaviour with Undefined Values
- Dissecting the "Starry obfu"
- The case for distributed version control systems
- Perl 6: Failing Softly with Unthrown Exceptions
- Perl 6 Compiler Feature Matrix
- The first Perl 6 module on CPAN
- A Foray into Perl 5 land
- Gabor: Keep going
- First Grant Report: Structured Error Messages
- Second Grant Report: Structured Error Messages
- Third Grant Report: Structured Error Messages
- Fourth Grant Report: Structured Error Messages
- Google Summer of Code Mentor Recap
- How core is core?
- How fast is Rakudo's "nom" branch?
- Building a Huffman Tree With Rakudo
- Immutable Sigils and Context
- Is Perl 6 really Perl?
- List.classify
- Longest Palindrome by Regex
- Perl 6: Lost in Wonderland
- Lots of momentum in the Perl 6 community
- Monetize Perl 6?
- Musing and the future of feather and the Pugs repository
- Musings on Rakudo's spectest chart
- My first executable from Perl 6
- My first YAPC - YAPC::EU 2010 in Pisa
- Trying to implement new operators - failed
- Programming Languages Are Not Zero Sum
- Perl 6 notes from February 2011
- Notes from the YAPC::EU 2010 Rakudo hackathon
- Let's build an object
- Perl 6 is optimized for fun
- How to get a parse tree for a Perl 6 Program
- Pascal's Triangle in Perl 6
- Perl 6 in 2009
- Perl 6 in 2010
- Perl 6 in 2011 - A Retrospection
- Perl 6 ticket life cycle
- The Perl Survey and Perl 6
- The Perl 6 Advent Calendar
- Perl 6 Questions on Perlmonks
- Physical modeling with Math::Model and Perl 6
- How to Plot a Segment of a Circle with SVG
- Protected Attributes Make No Sense
- Publicity for Perl 6
- PVC - Perl 6 Vocabulary Coach
- Fixing Rakudo Memory Leaks
- Rakudo architectural overview
- Rakudo Rocks
- Rakudo "star" announced
- My personal "I want a PONIE" wish list for Rakudo Star
- Rakudo's rough edges
- Rats and other pets
- The Real World Strikes Back - or why you shouldn't forbid stuff just because you think it's wrong
- Releasing Rakudo made easy
- Set Phasers to Stun!
- Starry Perl 6 obfu
- Recent Perl 6 Developments August 2008
- The State of Regex Modifiers in Rakudo
- Strings and Buffers
- Subroutines vs. Methods - Differences and Commonalities
- A SVG plotting adventure
- A Syntax Highlighter for Perl 6
- Test Suite Reorganization: How to move tests
- The Happiness of Design Convergence
- Thoughts on masak's Perl 6 Coding Contest
- The Three-Fold Function of the Smart Match Operator
- Perl 6 Tidings from September and October 2008
- Perl 6 Tidings for November 2008
- Perl 6 Tidings from December 2008
- Perl 6 Tidings from January 2009
- Perl 6 Tidings from February 2009
- Perl 6 Tidings from March 2009
- Perl 6 Tidings from April 2009
- Perl 6 Tidings from May 2009
- Perl 6 Tidings from May 2009 (second iteration)
- Perl 6 Tidings from June 2009
- Perl 6 Tidings from August 2009
- Perl 6 Tidings from October 2009
- Timeline for a syntax change in Perl 6
- Visualizing match trees
- Want to write shiny SVG graphics with Perl 6? Port Scruffy!
- We write a Perl 6 book for you
- When we reach 100% we did something wrong
- Where Rakudo Lives Now
- Why Rakudo needs NQP
- Why was the Perl 6 Advent Calendar such a Success?
- What you can write in Perl 6 today
- Why you don't need the Y combinator in Perl 6
- You are good enough!
Tue, 04 May 2010
The case for distributed version control systems
Permanent link
Currently the parrot developers are discussion whether to ditch svn in favor of another distributed version control system, maybe git.
I'm not a very active parrot developer, so my opinion probably doesn't count that much, but I still want to share a story, and then my opinion.
The story
Back in 2007 I was bored. I read about Perl 6 and pugs, and decided to check it out. And then I found a broken link on the pugscode website. And since I tried to be a nice guy, and I was bored, I decided to inform the developers.
So I joined #perl6, and told the developers about the broken link. No more than 5 minutes later had the awesome Audrey Tang done three things:
- Fixed the link.
- Told me in which file of the repository the fix was.
- Sent me a commit bit, so that I could make such fixes in future, too
I was very impressed by this display of openness, and stayed. Granted, there were some other reasons for staying too, but it did leave a very good impression.
Roughly a year (or maybe two) I had a doc patch for the Perl 5 core documentation. And I was surprised and disappointed to find that perl 5 (at that time locked into perforce) didn't even offer public read access to its version control system.
What we can learn
I've shared my short, romantic story with you because I think we can learn something from it: openness pays off, and being closed deters contributors.
I'm well aware that the parrot contributors can't hand out commit bits as openly as pugs (mostly for legal reasons; also it's a quite different stlye of development). But still a distributed version control system (DVCS) offers some of the openness that Audrey lured me with. With a DVCS the new developers can work just the same way as the core contributors, easily stack changes, bisect regressions and so on.
This social aspect of development is, in my opinion, a strong point for DVCSes. There are other reasons which speak for it; the strongest is probably that DVCS support both the central and the distributed development styles, while central CVS only support their own style.
Git vs. other DVCS
By now it should be clear that I propose to migrate to a distributed version control system. Any decent DVCS would be fine by me. I prefer git, because it's what I'm familiar with, and because it has very good performance characteristics.
I also like it because it has a feel similar feel to perl; many powerful built-ins, some of which are used day to day, others to explore if you have an usual problem or setup.
In short, I like git.
Comments / Trackbacks:
Trackback URL:
/blog-en/perl-6/distributed-vcs.trackback
Luc St-Louis wrote
Another plus for git: the index
Aristotle Pagaltzis explains it well:
http://plasmasturm.org/log/gitidxpraise/
brian d foy wrote
When I switched the perlfaq to github, many more people starting working on it. I think I had more patches in the first three months on Github than in the previous 8 years combined. I like git, but I think that was more to do with the awesomeness and ease of Github.
Nilson wrote
I'm not sure if it's desirable for a project like parrot, which is supposed to be cross-platform, to rely on a inherently not cross-platform VCS.
Git has great features - but try using it on Windows.
I guess it really boils down to who do you want to target. If you want to broaden the demographics of potential contributors, SVN would be the inclusive choice. If you prefer to intentionally "filter" some people, then maybe Git is a good choice.
supernovus wrote
Nilson: There are a few git for Windows ports, including graphical interfaces that make it as easy to use as SVN. I would recommend checking out Git Extensions, which I use on my Windows-based netbook.
The benefits of a distributed version control system greatly outweigh the deficiencies.
Nilson wrote
I've used msysgit in the past and I noticed a few days ago that there is a TortoiseGit (although I didn't test it yet).
I'm not saying that it isn't possible to use Git on Windows. I'm just saying it's a pain. I remember facing a lot of weird issues because of Cygwin.
Git has awesome features, but msysgit just felt like an alien experience on Windows. Personally, I expect VCS to not stand in my way.
Of course, if you judge that possibly alienating potential Windows contributors is worth the DVCS benefits, it's also a valid choice.
Jakub Narębski wrote
msysGit is native MS Windows implementation of Git
@Nilson: actually msysGit is native git implementation for MS Windows, contrary to git in Cygwin which uses POSIX compatibility layer. Nevertheless I agree that MS Windows is a bit second-class citizen... mainly because of lack of contributors.
Write a comment
The comments on this blog post have been disabled; the comment form below will not work.