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."
But... is Perl now historical only? (Score:3, Insightful)
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.
$.02
Re:But... is Perl now historical only? (Score:5, Insightful)
Mods on crack (Score:3, Insightful)
Re:Darcs vs. Git (Score:5, Insightful)
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: Perl not historical only (Score:5, Insightful)
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.
How about gitting CPAN? (Score:2, Insightful)
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.
Re:I'd rather seen they moved to Subversion (Score:5, Insightful)
I am intrigued git and adoption by a major project like Perl is a big endorsement, so please don't take this as a rhetorical question: isn't centralization the heart of source code management? As a project lead, I'm reluctant to have repositories sprouting like mushrooms everywhere and everybody having their own little "trunk," and developers arguing who should have to merge with whom before each release. Is this reluctance totally unfounded, or easily solved administratively, or a valid concern with a peer-to-peer SCM model?
Re:I'd rather seen they moved to Subversion (Score:3, Insightful)
that, and exploding checkouts for all users if your repository also contains binary data like media (images, music, videos).
Re:I'd rather seen they moved to Subversion (Score:4, Insightful)
Other posters have gotten the main ones, but a few points you may have missed:
First, yes, you can use it in a centralized manner. It does that much better than Subversion does. For a taste, use git-svn -- crippled, but in many ways better than vanilla subversion.
To address your actual concerns, though:
I'm reluctant to have repositories sprouting like mushrooms everywhere and everybody having their own little "trunk,"
The fact that everyone has their own "repository" as a working copy doesn't mean there have to be "repositories sprouting like mushrooms". You can do that, and it works well -- see Github -- or you can just have one "canonical" repo that everyone pushes to, or both.
Or you can have other models -- I believe Linux is hierarchical, such that various subsystems each have their own maintainers, with their own subsystem-specific repository. Some large patches, like suspend2 or the Ubuntu patches, certainly maintain their own repositories. But it's actually quite easy to send relevant changes back up the chain -- Linus can pull from whichever of those he wants, and apply them to the official tree.
In fact, that's something much more difficult to do on Subversion -- having only one person with commit access would be stifling. On the other hand, with Git, commit access can be based on trust, not on productivity.
Just as an example: When I want to make a non-trivial change to a project on Github, I just fork it. Then, when I'm satisfied with my changes, I send a pull-request back. There's no question as to which is the "official" version -- on the other hand, if my change really is a good idea, and they refuse to merge, maybe I'll just keep developing on my own, merging in their changes, and before long people are seeing me as the "official" version.
and developers arguing who should have to merge with whom before each release.
But the problem of which version is official, and who needs to merge with whom, is a social, not a technical problem. You have the exact same problems with SVN, if you use it properly -- we tried this for a bit, with everyone working on their own branch. Merging was impossible, even though there was a "real" trunk. (Or, I should say: It was possible, but expect to wait a half hour or more for SVN 1.5 to figure it out -- or expect to spend a half hour or more of your own time giving SVN 1.4 the right revision ranges.)
Then we started using git-svn, everyone working off trunk, and keeping their own private Git branches locally. This way, merging was trivial, because Git is awesome at merging. The downside is, local Git commits get turned into git-svn commits when you send them to SVN, which changes the sha, which makes it that much harder to merge any other local branches you might have -- it was definitely an upgrade to start some new projects on pure Git.
Re:This story was a surprise to me (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 does continue and you notice they do make releases very often to make Perl 5 better. I dont really quite understand that one would allow the delay with Perl 6 cause them to stop using Perl 5 when Perl 5 is indeed a very capable language.
Perl 5 can also embed into Apache and has been able to do so for a long, long time so there is no excuse to not use it as an embeddable in web pages like PHP.
I do think a mistake with Perl 6 was not focusing more on the compiler first, making Perl 5 the first target of the Perl 6 compiler, so that more drawn out VM work wouldnt slow down Perl 6 development. . In perl 6 a from scratch rewrite was chosen. This may have been an important choice depending on the extendability of the Perl 5 systems. I have not taken a look at Perl 5 much so I cannot comment if the system is extendable or was worth expanding and extending. It is a good idea to keep the compiler parts seperate from the interpretor and from what I have heard Perl had some issues in this area.
Perl 5 will continue to be avialable for use of course, and I expect a bridge to exist between Perl 5 and Perl 6 to allow them to interoperate. There is so much XS code out there that Perl 6 calling the perl 5 VM to run modules is going to have to be a part of the the system.
Re:This story was a surprise to me (Score:1, Insightful)
Perl 5 OO is not hard man. A class is a package (module). An object is a bless'd reference. You create functions in the package that do operations on the object(s) in the class. That's it, basically. You can use whatever variable types you want to store class data. Hashrefs are common and easy to deal with, and pretty damn transparent so you can see what's going on under the hood of the OO stuff if you really want to (nice for educational purposes). But really isn't not hard. It's much easier to understand than Java or other OO implementations that try to hide everything and will assault you with a shotgun if you enter their living room [ that's a reference to Perl Programming OO chapter btw ;-) ]
Re:it depends on the size, I think (Score:3, Insightful)
1A->B->C->E->F->H
1...\->D--^->G--^
Unfortunately, the problem with earlier SCM's is that in creating state H they try to merge both D and G into F. They forget that D was already merged into E, and try to merge it in again. This obviously causes problems; either conflicts; or even worse, mysterious code duplication or deletion.
To work around this, many coders made scripts that recorded the previous merge point through automated tags or other magic. Unfortunately, the diagram I showed above is a relatively simple case. The history graph can be much more complicated, and simple scripts will break.
Git solves all of this by knowing the topology of the ancestry diagram. It knows exactly what has been previously merged, and what hasn't. This means when multiple branches are merging between themselves it "just works".
With subversion, don't you merge a specific range of revisions, such as "C->G" in your example?
Also, while maybe not as nice as git's merging, isn't subversion 1.5's merge-tracking exactly what you're talking about? Now the range of revisions doesn't need to be specified, AFAIK.
source [red-bean.com]
I'd love to hear from anyone who has both git and svn experience. I't be interesting to know if there are any features that would benefit smallish teams, or if subversion has more or less been keeping up in that area.
One more "I only know git because when I was looking at code versioning systems it looked cooler than CVS" post is gonna make me throw up.
Re:it depends on the size, I think (Score:3, Insightful)
All of those problems go away when you can easily merge, because then branches cease to be painful - but then I've found that the best merges Git makes are the ones you get from rebaseing or cherry-picking, which SVN cannot do.
When was the last time you used SVN? Everything you just said is very confusing, 1.5 came out over a year ago and seems to have most of the features you say it does not.
http://subversion.tigris.org/svn_1.5_releasenotes.html [tigris.org]
http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchmerge.cherrypicking [red-bean.com]
As for rebasing, this is the first I've heard of it. It sounds interesting, but I don't really understand the problem it was meant to solve.
From http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#using-git-rebase [kernel.org]
Suppose you are a contributor to a large project, and you want to add a complicated feature, and to present it to the other developers in a way that makes it easy for them to read your changes, verify that they are correct, and understand why you made each change.
If you present all of your changes as a single patch (or commit), they may find that it is too much to digest all at once.
If you present them with the entire history of your work, complete with mistakes, corrections, and dead ends, they may be overwhelmed.
Just seems a little superficial to me :\ A single patch is too much, the actual VCS history is too much, so the ideal is offering a doctored up change history?
Wouldn't the end result be more interesting? I think good source comments with other documentation would be easier to understand and more proper than reviewing the change history of someone's patch.
Since when was how someone's patch was developed more important than what was developed? Isn't diving into the VCS to find reasons for something being just a sign that the code wasn't documented properly? So, yes, we dive into VCS history to solve preexisting documentation problems, but when it comes to accepting someone else's patch, isn't that the time to simply demand good comments and or documentation?
I like what I've heard of DVCS systems so far, but I don't see what the mad rush to git is all about. Maybe it just makes more sense in the OSS context where a bunch of strangers are working on a project, wherever, whenever they want to. *shrugs*
Re:I'd rather seen they moved to Subversion (Score:3, Insightful)
Can you elaborate on this?
The specific scenario I use SVN for is where a single repository (not svn:externals, which I agree are broken, though for other reasons) has several related but independently developed projects, and a couple of "common" projects shared by all (mostly library-type functions). Using svn we can check out these individual folders easily, work on them independently, and ignore completely (ie: never check out) folders for projects we aren't involved in. It is possible and easy to copy files from one project to another, retaining history. I do this semi-regularly, for example when a "common" change necessitates the creation of a supporting object in several of the other projects, I create the common object, create the supporting object (which inherits from the common object), then copy+history that supporting object to the other projects which need it (making changes as I go).
I'd expect git, which seems to be all about decentralization, to at least have a similar option, perhaps retaining history (no clue how) when copying from one repository to another. I would expect that the ability for different "Open Source" projects to share code easily would be a priority, but I guess that's not the case.
Trying to learn git a few months ago, I started up a handful of projects which had some similar needs. I quickly learned that in git, things were either the same project or entirely unrelated, and that sharing common files between them would mean having an entirely separate library which I could commit changes to with about as much ease as an SVN:External. Less ease, really, as git chose to silently squash changes I made when a common command, through use of git submodules, turned lethal. Googling revealed that submodules were really just a clever hack at this point and that it would silently eat changes if you didn't use some specific and very-hack-feeling commands to update.
Perhaps git is only for completely-encapsulated projects (which is what I currently use it for- one shot scripts that I'd rather version than be sorry about), or for very very mature projects, which have already made all their decisions about what goes where, and who owns what. For starting a new project, where I wasn't sure what would be shared, what wouldn't, and what was truly related, I found git clunky and tedious.
Re:I'd rather seen they moved to Subversion (Score:2, Insightful)
The other big advantage is that when you start using a distributed VCS like git, the performance difference is so large that you find yourself using it a lot more. For example, you might notice that your developers start committing smaller atomic changes (rather than full days work at the end of the day) or they'll be more willing to create branches for different tasks because merging them back is easy in git and not so much in svn.
Also regarding your question about developers arguing who should merge with whom, a VCS isn't a replacement for communication. Git will allow developers to try out different ideas easier and allows easier offline collaboration, but at the end of the day, as the project lead you are responsible for what goes into the "official" repo and what doesn't. So you can still have a central place where releases are made (like your own local repo or one on a central server), but with git the development process is a lot more flexible.