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."
Re:Darcs vs. Git (Score:5, Interesting)
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:
Re:I'd rather seen they moved to Subversion (Score:1, Interesting)
I agree. I think you have to understand how Git works at a lower level in order to use it. If you've only got the high level conceptual view, good luck.
Slap a Perforce-like CLI on top of Git and I'll be all over it.
git-gc increases disk usage for Perl (Score:1, Interesting)
A checked out git tree of Perl using git-clone is 151MB. If you run git-gc --aggressive, it increases to 225MB.
Has anyone seen this behavior before? All of the projects that I track either decrease in size or remain the same. I've never seen one jump up in size after telling the GC to run.
I'm using git 1.5.6.5.
Re:I'd rather seen they moved to Subversion (Score:1, Interesting)
Its not really an issue. In general there is a "canonical" repository. The others are just convenience, or working enviornments or whatever. In fact the canonical repository is more often than not a "bare" repository. Whereas the others will have WD's and possibly many remotes.
So you dont really worry about it, unless you are overly paranoid about people forking your project.
Re:How about gitting CPAN? (Score:3, Interesting)
They're working on Git/CPAN patching functionality [perl.org]. I imagine that other interesting combinations of the two will be seen in the near future.
Re:Darcs vs. Git (Score:3, Interesting)
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, but may not be so relevant in the future if either Git or Mercurial garners substantially more mindshare than the other. We would, ideally, like to stay ahead of the trends...
This story was a surprise to me (Score:5, Interesting)
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:But... is Perl now historical only? (Score:3, Interesting)
"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 answer to everything. Design is still required.
The reason? If perl6 did something wrong, you might have no idea that it's wrong, and use the feature. Now it will probably lead you down a bad path somehow, and even if you don't care, they have to support it. Just like if you start driving on a bridge -- everything seems great to you, and once you are on the bridge you expect it to not fall down.
Some things you design carefully, like interfaces that will need to be supported for a long time, languages, anything that you rely on to hold or process important data, performance-critical algorithms, etc. In other words, any kind of platform needs a lot of design work.
Re:Darcs vs. Git (Score:2, Interesting)
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:
In Hg's favor, Git has no (useful) GUI, but it didn't take long to learn the five or six commands I actually use regularly, and Git's documentation is very good so that was kind of a moot point.
Re:Darcs vs. Git (Score:3, Interesting)
My primary reasons for strong preference for git over hg are the following:
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 line of development.
Hg has a really nice and malleable history via the MQ extension that has quilt like qualities. Which is really, really nice. The problem with it is that once I publish it for someone else to review it, it's not malleable any more (or not as malleable). Maybe that's gotten better, but since I last looked at it, it sucked in comparison to using git-rebase, or one of the Stgit or whatever it was that added quilt like commands to git. Using git, I can publish a branch, get review and commentary, quickly fix the malleable history and re-publish it. Once it passes all review and testing, once integrated into the "mainline", all of the history will be extremely high quality. There will be far fewer commits that are fixed 2 commits later when somebody reviews the code.
git-svn is absolutely wonderful for interacting with SVN repository. My company can use SVN, and I can use git on my machine and work, and re-work a series of small quality commits and then push them to SVN in a automated way. I'm not sure I'd reorganize an SVN repository via it. (Not sure this yet works on Windows).
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. In git, I can have a commit that has no children and delete that branch, and it disappears. I can reset a branch to be at any point I like, and it'll be there no matter what else I do.
In the end, Mercurial makes it harder for you to do something "bad" like re-write history too far back in time. At points that is very limiting. Git on the other hand hands you all the chainsaws, if you cut off your legs, they figure that's your problem. In the end, git lets me do what I need to.
I'm a bit of a VCS junkie, so complex interfaces didn't bother me. Once I understand the model of a VC system, I can quickly adapt to it.