Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×
Perl Programming IT Technology

Perl Migrates To the Git Version Control System 277

On Elpeleg writes "The Perl Foundation has announced they are switching their version control systems to git. According to the announcement, Perl 5 migration to git would allow the language development team to take advantage of git's extensive offline and distributed version support. Git is open source and readily available to all Perl developers. Among other advantages, the announcement notes that git simplifies commits, producing fewer administrative overheads for integrating contributions. Git's change analysis tools are also singled out for praise. The transformation from Perforce to git apparently took over a year. Sam Vilain of Catalyst IT 'spent more than a year building custom tools to transform 21 years of Perl history into the first ever unified repository of every single change to Perl.' The git repository incorporates historic snapshot releases and patch sets, which is frankly both cool and historically pleasing. Some of the patch sets were apparently recovered from old hard drives, notching up the geek satisfaction factor even more. Developers can download a copy of the current Perl 5 repository directly from the perl.org site, where the source is hosted."
This discussion has been archived. No new comments can be posted.

Perl Migrates To the Git Version Control System

Comments Filter:
  • by Dan667 ( 564390 ) on Sunday January 04, 2009 @12:55PM (#26320753)
    but this is fantastic. I use perl every day and love it.
  • by berend botje ( 1401731 ) on Sunday January 04, 2009 @12:57PM (#26320771)
    This must be the sign. Any day now The Announcement will come: "Perl Six is Ready!".

    And there will be much rejoicing!

    Seriously, I can't wait!
    • This must be the sign. Any day now The Announcement will come: "Perl Six is Ready!".

      And there will be much rejoicing!

      Seriously, I can't wait!

      Right after majordomo 2.

    • Re: (Score:3, Funny)

      by CarpetShark ( 865376 )

      Actually, this is an intermediate step. They now know how to tag perl 6, if/when it does arrive.

    • "Yeah, going out of business." -- Janine Melnitz, Ghostbusters.

  • I can understand the advantage of using distributed version control. But given all the Haskell people involved (who came in via Pugs) I'm surprised they went with Git vs. Darcs.

    Does anyone know if speed is as large of an issue as it is for Linux kernel or was there another reason?

    • Re:Darcs vs. Git (Score:5, Insightful)

      by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Sunday January 04, 2009 @01:25PM (#26321003) Journal

      I would guess it's ubiquity and featureset.

      Git is built of a patchwork of C and scripts, meaning it's something Perl6 could be a part of someday, and it's also something that's going to be quite familiar to all Perl developers, not just the Pugs guys.

      And, Git seems to be quickly becoming the Subversion of DVCS -- fast, open source, everyone has it, everyone knows it, and the alternatives really don't have much compelling to offer.

      • Re: (Score:3, Interesting)

        by r7 ( 409657 )

        the alternatives really don't have much compelling to offer

        This is what I have been wondering about. One of the alternatives, Mercurial, does seem to be a compelling alternative to GIT. Would love to hear from anyone who has used both, especially WRT migrations from CVS and integration with Trac. We've been leaning towards Mercurial as it is mostly written in Python (vs C), implements much the same functionality in 1/3rd as many lines of code (according to http://www.infoq.com/articles/dvcs-guide [infoq.com]), and is used by Mozilla, Sun, etc.

        These comparisons matter now, b

        • Re: (Score:2, Interesting)

          by n dot l ( 1099033 )

          When I was considering migrating from SVN to Git I checked out Hg as well since people were making a big deal bout it having a sane Windows UI and all that jazz (and we do a bunch of work on Windows at work). I admit I didn't do a very deep comparison, so maybe I'm selling Hg waaay short here, but Git impressed me and Hg didn't - Hg fans, correct me if I'm being ignorant. The things that stood out in my mind are:

          • Git was noticeably faster for almost everything.
          • Git had more options for rewriting history.
          • Git's
          • by doom ( 14564 )

            Git's SHA-hash-as-identifier feature is just plain sexy, especially since they can't ever get out of sync as Hg's revision numbers can.

            Monotone is built around that idea, and existed before git.

            The real reason we're all migrating to using git is that it was endorsed by a celebrity.

            It may seem like a silly reason, but it beats wading through the hand-waving and screaming surrounding yet another technical religious war.

            • actually, the real reason is that it works as advertised, is damn fast and there's a Really Big and Important Project using it - namely, the Linux kernel. any sane person will admit that if a project of such size is using something, then it's at least an option to consider.
              OTOH, hg is used by openjdk and mozilla, and bzr by launchpad (which means shuttleworth's $$$ are behind it.) it's not like there's no choice, the principles are similar.
          • Git's SHA-hash-as-identifier feature is just plain sexy.

            Just like Mercurial. Actually all DVCS compute the hash of (parent revs + new content) to generate the child revision identifier.

        • Re:Darcs vs. Git (Score:4, Informative)

          by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Sunday January 04, 2009 @04:14PM (#26322263) Journal

          The main things I like about git are its raw speed, its ubiquity (everyone and their dog has a git tutorial), and how simple its primitives are.

          That is: I actually started with bzr, and I found that while there were some things that were much easier (bzr uncommit comes to mind), it's a lot easier to actually understand Git under the hood, in case I need to do some deep surgery on some history, say.

          Then, too, there just seem to be more tools available -- gitk, git-cherry-pick, even git-stash, are things I don't remember from bzr or hg, but it's been awhile.

          I see the point about Python, and I'm absolutely with you there. The reason it's not an issue is, I can't ever remember having to dig into Git source -- the most I might have to do is write a shell-script frontend to some of the tools already there. It's actually somewhat UNIX-y that way -- when was the last time you had to dig into the source of fileutils?

          What's more, there are language bindings -- personally, I've used grit in Ruby. Easier than trying to talk to SVN with its XML output.

          The main advantage of bzr, by the way, is its handling of directories -- it actually records renames. Git tries to detect them, but it works at the level of file contents, not directory structure -- so, for example, it'll detect if you move a function from one file to another, but it might have trouble if you rename a directory. For example:

          mv a b
          mkdir a

          And, in another branch:

          touch a/c

          When they merge, where should c go? Git would probably put it in a, since the file's name is 'a/c'. Bzr would probably put it in b, since a was renamed to b, unless the same rename somehow made it into that other branch.

          There is another reason I didn't mention -- I use Ruby. I believe Ruby itself is done on SVN, but it seems that every Ruby project ever has moved from SVN to Git, and most of them to Github. And it's just awesome to work with Github projects.

        • Re: (Score:3, Interesting)

          My primary reasons for strong preference for git over hg are the following:

          • Lightweight Branches
          • History is malleable.
          • git-svn
          • git "heads" are explicit

          Hg is oriented in such a way that the "easiest" workflow is to have multiple branches in multiple different branches. In git, I have exactly one working copy that has all of my history. If I'm making a minor nit change, or a huge sweeping change it all happens in a single directory. Hg generally wants a separate directory/working copy for each branch or li

          • In Mercurial, heads are deduced by a commit which has no children. So any commit lying around is something that has to be dealt with.

            Not true. Use "hg strip" (mq extension) to remove a branch.

    • Re:Darcs vs. Git (Score:5, Interesting)

      by Johnny Loves Linux ( 1147635 ) on Sunday January 04, 2009 @01:31PM (#26321031)

      I can understand the advantage of using distributed version control. But given all the Haskell people involved (who came in via Pugs) I'm surprised they went with Git vs. Darcs.

      Does anyone know if speed is as large of an issue as it is for Linux kernel or was there another reason?

      Actually, you might not know this, but the Haskell folks already moved over to git from darcs a while ago. They were having scalability issues and did a 6 month survey to determine which distributed version control they should go with and determined that git was the best of the breed. Here are the links:

      1. Announcement: http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/14819 [gmane.org] [gmane.org]
      2. Comparisons: http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation [haskell.org] [haskell.org]
      • by jbolden ( 176878 )

        Wow that is interesting, thank you. For GHC to be moving away from Darcs is a serious blow. Linux had the same issues so that seems to mean that the GHC feature set isn't good enough for large applications. But the real advantages of distribution happen with large applications.

        Excellent information!

  • by Slartibartfast ( 3395 ) <kenNO@SPAMjots.org> on Sunday January 04, 2009 @12:59PM (#26320789) Homepage Journal

    I mean, really. Git's good -- git's even really good -- but what does it matter if Perl 6.x is gonna take longer than Duke Nukem Forever to come out? It's the clear and obvious winner of the OSS vaporware award. [And, yeah, I'm aware that there are beta releases -- or, at least, pre-releases -- but "where's the beef" already?] I'm not a big fan of ESR, but I have to admit "release early and release often" is something I happen to agree with.


    • by berend botje ( 1401731 ) on Sunday January 04, 2009 @01:00PM (#26320797)
      I take it you have volunteered to help finish P6?
    • I mean, really. Git's good -- git's even really good -- but what does it matter if Perl 6.x is gonna take longer than Duke Nukem Forever to come out?

      Maybe Git will help it come out sooner. I know I'd much sooner contribute if I could just fork the project on Github, as opposed to sending patches against a Perforce repository.

      And be careful with the DNF jokes. We said the same about Vista, and look what happened.

      I'm not a big fan of ESR, but I have to admit "release early and release often" is something I happen to agree with.

      Then you obviously missed that point. "Release early and often" is about making the code available, and there are beta/prereleases available for Perl6, so they've got that covered.

      It absolutely should not apply to final versions. Those should be

      • What people often forget however is that part of 'release early, release often' is 'release something useful'.

        If something is perpetually in [true] beta, and doesn't appear to do anything useful yet (can I start coding my perl6 apps yet? sure. I can, but the specific details of the language are still in flux and MAJOR bugs are still being fixed, so I cannot write things in perl6 and rely on them to work).

        I'm also still waiting for perl5 to be written for parrot. Then I can start mixing and matching my perl6

        • I'm also still waiting for perl5 to be written for parrot.

          Ponie is written. I'm guessing it's not complete.

          A similar problem is that although I can write things for Perl6 (pugs or parrot) I cannot expect other people to have pugs or parrot in their distro, and thus be able to use them.

          Coming from Perl, that is a problem. But that's also true of Ruby, and until recently, Python. As it is, parrot is available in Ubuntu, and you don't need pugs to run a bitecode-compiled Parrot app -- I believe pugs can compile it, though. And I don't see that as a huge problem -- after all, if you were writing a Perl5 app, and doing it right, you would be relying on tons of CPAN modules too.

    • by Dystopian Rebel ( 714995 ) * on Sunday January 04, 2009 @01:31PM (#26321029) Journal

      Fixed the subject line for you.

      Last year, I completed two important Perl-based projects for my employer. I also use Perl at least once a week to run analyses of my Web server logs. I prototype Web applications in Perl and often just put the prototype into production because it works well. I'm still using Perl that I wrote over 10 years ago, with NO changes, on several OSs. And I use Ubuntu Debian, of which Perl is an integral component.

      Perl is great. If I want what it doesn't have, I use a different language. But when I want regular expressions, CPAN, quick and secure CGI, analysis of large data sets and general parsing, easy database integration, and efficient portability from server all the way down to embedded systems, Perl is the first language I consider. Ruby might be ready for the real world one day. And Python is good for other things, but it is not a replacement for Perl.

    • Re: (Score:3, Informative)

      by jbolden ( 176878 )

      If you just want Perl6 you can use it today with Pugs. That is the "release often" and it finished.

      If you want a real release candidate the problem is Parrot. Perl6 attempted some very complex stuff with the runtime, that so far has been challenging to implement. There is no guarantee these problems will get solved.

    • by thanasakis ( 225405 ) on Sunday January 04, 2009 @03:01PM (#26321717)

      You can use Perl 6 right now if you want. It is available, just not rated for production yet. I can understand that probably not many folks will want to use it for real world purposes, but this is pretty far from at least my definition of vapor.

    • Re: (Score:3, Interesting)

      by jadavis ( 473492 )

      "release early and release often" is something I happen to agree with

      Really? What about other design projects, like building a bridge? Should they release early and say "tell us if it collapses, and we'll fix the design"?

      With all this talk about agile programming -- in which you just keep adjusting things until someone says "good enough for me" -- sometimes people forget that design is important, too. Agile development is certainly a valuable tool for many kinds of development projects. But it is not the an

    • by thue ( 121682 )

      but what does it matter if Perl 6.x is gonna take longer than Duke Nukem Forever to come out?

      For the curious, Duke Nukem Forever was announced April 28, 1997, which Perl 6 was announced 19 July 2000.

      I will be interesting to see which one will finish first :).

      Of course there is also GNU Hurd [wikipedia.org], which began development in 1990 and is still not production ready...

  • by djupedal ( 584558 ) on Sunday January 04, 2009 @01:20PM (#26320961)
    $ git clone git://perl5.git.perl.org/perl.git

    -bash: git: command not found
    • Maybe you forgot to emerge it?

      ~ $ eix dev-util/git
      * dev-util/git
      Available versions: ~ ~ ~ ~ ~ ~ ~ ~ ~1.6.0 ~ ~ ~ ~ ~ ~ {bash-completion cgi curl cvs doc elibc_uclibc emacs gtk iconv mozsha1 perl ppcsha1 subversion threads tk vim-syntax webdav xinetd}
      Homepage: http://git.or.cz/ [git.or.cz]
      Description: GIT - the stupid content track
  • by Anonymous Coward

    I propose using Git for CPAN too.
    Can be cool - if you want to make changes to a module that is not yours, you should be able to branch it, make the modification, and offer the branch to the original author.

    and it can be better - operate against your personal branch of CPAN.

  • by qazwart ( 261667 ) on Sunday January 04, 2009 @03:13PM (#26321801) Homepage

    My first response was "Do they still develop Perl?"

    When I first started with Perl 3.0 many, many years ago, I fell in love with the language. It was flexible, powerful, and could do all sorts of amazing things. Version 5.0 brought in objects, but the way they worked was a little kinked. Defining classes in Perl is not easy, and I always have to go back to the manpage to make sure I've got all the incantations. Many times, I simply use object oriented structures and forgo the object definitions.

    Perl 6 was suppose to fix everything. It would improve the way class definitions worked. Perl 6 would be a better object oriented language while still allowing you to hack out quick scripts like you would in shell script.

    Well, Perl 6 was announced almost a decade ago, and it still isn't released. Meanwhile, Python has become the defacto scripting language for the OSS world. Even I, a Perl fanatic whom makes most Mac fanatics look mellow have to admit that, and learn Python. I hate Python. It's use of indents for flow control is a throwback to Fortran. Its lack of regular expressions in the string object (you have to import a special "re" object) makes it maddening. Why o' why does Python use "pop" for arrays, but not "push"? What were the designers on when they decided "exists" is not a member function of hashes -- excuse me -- dictionaries and arrays? Why this syntactic distortion of over 50 years of computer programming overturned?

    But, I am now a good Python developer writing all of my stuff in Python. I am use to the cryptic error messages that don't really explain the problem (after all, Python has only been around for a bit over a decade). I am use to the fact that basic structures of the language change from implementation to implementation. I even like the fact that "numbers" are divided into multiple types although you really can't declare a number to be a specific type. It does allow you to experience the fun of your division suddenly not working because it is INTEGER division. (And, of course, Python 3.0 will change this very basic part of implementation and break everyone's Python script!)

    Perl could have been the language of the web. After all, even Perl has fewer syntactic quirks than PHP, but it is PHP that is the glue behind server side webpages. While the Perl gurus were redesigning Perl, PHP got incorporated into an Apache module and added the syntactic sugar needed to run sessions and keep variables between PHP scripts.

    So, Perl, the glue that use to keep the Internet flowing has become a niche language. Almost all of the younger developers I know never bother to learn it, and fewer and fewer jobs are interested in it. It is Python that everyone wants. It is PHP that runs the message boards and CMS pages. Perl is simply no longer in the picture.

    Every few years, something I've learned becomes obsolete. It's the field. One time, I knew how to setup a UUCP network. One time, I could setup a Gopher site. I also learned all the quirks of HTML 3.2 and had to lose that to learn CSS. I use to know C shell programming, and of course I was a C developer and an expert in the curses library. I've usually gave up these technologies without too many problems.

    Perl is different. I've been a Perl developer for over a decade. I've always loved the language, and I've solved many, many issues with it. One place where I worked was a .NET development shop when they suddenly realized that some major component of their software couldn't retrieve the information from the network. It would take weeks to fix! I wrote a Perl script in four hours that took care of the problem.

    Another place I worked had damage in a customer's database. They had everyone in the company searching for problems and re-inputing the information by hand into a clean database. A Perl script I wrote in a couple of hours did the job. Perl made me the expert. I was the wunderkind. Perl allowed me to do the impossible. It was quick, hackish, yet could also be used to build powerful programs

    • Re: (Score:3, Insightful)

      I have used perl extensively adn one thing its OO is not is "complex". Bless is very easy to use, its a very simple model? It couldnt be easier.

      As far as rewriting your existing scripts for perl 6, i wouldnt do this. Use Perl 6 for new projects, use Perl 5 for old ones.

      Perl 5 remains a good quality platform for development so do not let the situation with perl 6 discourage you from using perl 5. Perl 5 is still a great development platform and is better than python and ruby in many ways.

      Perl 5 development

      • by dkf ( 304284 )

        I have used perl extensively adn one thing its OO is not is "complex". Bless is very easy to use, its a very simple model? It couldnt be easier.

        Theoretically, yes. But it's really a bit deep for most folks. In practice, it would have been better to have given something less flexible but with more syntactic sugar, since then it would have been easier for more people to have used it.

        Language design is a fine line between power and usability. (Well, it is for languages that have real merit; some are just weak and difficult, but they're really just curiosities.)

    • Why bother rewriting your scripts from Perl 5 to Perl 6? Why not simply rewrite them in Python and be done with it.

      Because Perl 6 will automagically run Perl 5 modules without the need for any translation, and because if you do want to translate a module there will be an automatic converter. In other words, a transition from Perl 5 to Perl 6 will be automatic and require little or no effort on your part, while a rewrite in Python would be a huge amount of manual work.

      The perpetual moaning on /. about th

    • What were the designers on when they decided "exists" is not a member function of hashes -- excuse me -- dictionaries and arrays?

      The main designer of Python [wikipedia.org] is a Dutch guy that worked in Amsterdam at the time, you do the math ...

  • So, hmmm, is there a TortoiseGit project for us lazy Windows users ? Which reminds me, is there a GUI for linux equivalent to TortoiseSVN ?
  • You guys know that, In the UK at least, git is a moderate insult with the same meaning as bastard? Why, just earlier today a friend of mine referred to me as a "Jammy Git".

    At least it will make any future lectures on Perl I attend more interesting.

You will have many recoverable tape errors.