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."
que the unreadability jokes (Score:5, Funny)
Re:que the unreadability jokes (Score:5, Funny)
Dear Perl Monger,
TMTOWTDI in Perl. However, in English spelling:
- Que Publishing is a publisher of computer books
- Q was an arrogant but powerful character in ST:TNG who liked to annoy the crew of the Enterprise because they didn't copulate anywhere near as much as James... T... Kirk.
- queue, noun, a line or series of people or things; verb, to form a line or series.
- cul, noun, French, the buttocks
- cue, noun, a signal or indication; verb, to signal, to indicate, to move to position.
2009: The Year Of The Truly Helpful Slashdot Grammar Nazi
Re:que the unreadability jokes (Score:5, Funny)
Qué?
Re: (Score:2, Informative)
You forget that Q also appeared in ST:V a few times.
2009: The Year Of The Truly Helpful Slashdot Grammar Nazi Watchmen
Re:que the unreadability jokes (Score:5, Funny)
Here is the script used to migrate perl to the git version control system:
#! /bin/perl
$T=s/Y9/s/0YT-sx^*%fr86%8 ^% v%^* %^* 8*R%^*f vR%^ print @V^58 *$$%&^*7890JH87gV7 65&ygtyR$KLJi"'"%$44:H{"['J{]09'[u"JOPu9)P{"Y8yghO*HYgT*gtO""i'G{*(#h'oiHIO*UYF&d97c 567F&Olf*(Up[;yh['
"[]i
O}{];{:}{;';}
jpJhi8[9
89ouyfo8tIGUYf65D 54$4$edc%$
Re: (Score:2, Funny)
Parent post is just gibberish, it is not a real Perl program.
Re: (Score:2)
Re: (Score:2)
Mod parent up. True slashdotter.
Re: (Score:2, Funny)
I ran your code and the output was 42.
This must be the sign (Score:4, Funny)
And there will be much rejoicing!
Seriously, I can't wait!
Re: (Score:2)
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)
Actually, this is an intermediate step. They now know how to tag perl 6, if/when it does arrive.
Re: (Score:2)
"Yeah, going out of business." -- Janine Melnitz, Ghostbusters.
Darcs vs. Git (Score:2)
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)
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)
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)
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:
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Just like Mercurial. Actually all DVCS compute the hash of (parent revs + new content) to generate the child revision identifier.
Re: (Score:2)
Re:Darcs vs. Git (Score:4, Informative)
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:
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
Re: (Score:2)
Not true. Use "hg strip" (mq extension) to remove a branch.
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: (Score:2)
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!
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)
Re: (Score:2)
There are too few developers working on Perl 6, adding a few would actually speed it up. There is a lot of work to be done, and people are spread too thin.
I volunteer ! (Score:5, Funny)
There are too few developers working on Perl 6, adding a few would actually speed it up. There is a lot of work to be done, and people are spread too thin.
I don't have a clue regarding perl, but looking at some perl scripts, I think I can do it. I mean all you have to do is type #! /bin/perl and roll your face over the keyboard.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
The development is still decentralized. And Github makes it that much easier to handle the social aspects -- it's like a social network of software development.
Aside from that, it's not really centralized. In a social sense, it's one click on Github to fork it, or you can manually fork it and push it to another service. In a technical sense, everyone's checkout is also a full repository/backup, so if Github ever implodes, there will likely be at least one backup for every active project on there.
Don't get m
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.
Re: (Score:3, Informative)
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.
Re:But... is Perl now historical only? (Score:4, Informative)
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)
"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
Re: (Score:2)
Can you name multiple agile advocates who've actually produced software who argue that design is not a part of agile development?
I'm not going to dig through people's blogs, but here's a wikipedia quotation:
"Customer satisfaction by rapid, continuous delivery of useful software" -- http://en.wikipedia.org/wiki/Agile_development [wikipedia.org]
Sometimes design work takes a long time. If you deliver a platform (be it a bridge or a programming language) before the design is complete, than the delivered product might be counte
Re: (Score:2)
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...
Can't get there from here (Score:5, Funny)
-bash: git: command not found
Re: (Score:2)
~ $ eix dev-util/git
* dev-util/git
Available versions: 1.5.1.6 1.5.3.7-r1 ~1.5.3.8 1.5.4.5 ~1.5.5.3 ~1.5.5.3-r1 ~1.5.5.4 ~1.5.6.1 ~1.5.6.2 ~1.5.6.3 1.5.6.4 ~1.5.6.5 ~1.6.0 ~1.6.0.1 ~1.6.0.2 ~1.6.0.3 ~1.6.0.4 ~1.6.0.4-r1 ~1.6.0.4-r2 1.6.0.6 {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
Re:Can't get there from here (Score:5, Informative)
The joke is that git depends on 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: (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.
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: (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
Re: (Score:2)
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.)
Re: (Score:2)
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
Re: (Score:2)
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 ...
Tortoise ? (Score:2)
Re:Tortoise ? (Score:5, Informative)
http://code.google.com/p/tortoisegit/
Bastard. (Score:2)
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.
Re:I'd rather seen they moved to Subversion (Score:5, Informative)
There are significant advantages of Git over Subversion. RTFS for some.
Just to add insult to injury -- often, a Git checkout, which includes all history, takes up less space than a Subversion checkout for the same project, which doesn't even include recent commit log messages.
But think about this -- you're saying they should use a big, slow, central server, as a single point of failure, crippling offline development, complicating branches (especially merges), and several orders of magnitude slower for just about every operation, just so you don't have to learn a "weird" tool?
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?
it depends on the size, I think (Score:5, Informative)
These distributed models work best if it's a large team, which potentially has more than one level of hierarchical structure.
You do typically have a canonical central repository managed by the project lead (in the Linux kernel's case, Linus's tree). But then sub-section leads might have their own canonical repository for that sub-section, and merge in their team members' changes into a stable state that they approve of before asking for those changes to get merged into the central branch. Or they might bundle up some particularly important set of changes for early merging "upstream", making sure they cleanly apply against the current central repo. That's all a nightmare to manage in SVN, which conceives of branches as something you do occasionally and keep around for a while, not as a hierarchical project-management tool.
On the other hand, if you have a relatively small or flat team, or one where the sub-sections break down really cleanly so each one can have its own central repo, it might not buy you much. I'm working on a small project with 4 people at the moment, and SVN is perfectly fine, and I can't really imagine what I'd do with a distributed version control system (I'd just use it like a centralized one, pushing everything to the one repo everyone pulls from).
Re:it depends on the size, I think (Score:4, Informative)
I can't really imagine what I'd do with a distributed version control system
Like I kept repeating in my other post [slashdot.org], you can actually use branches and commits as tools to aid your own work without affecting others or polluting the commit logs with junk "Work in progress" commits. That and you get sane merges. Both of those are huge, even if your team is just you and your imaginary friend.
Re: (Score:2)
Given that, and given that I haven't used another tool, what're you thinking of with "sane merges"? I'm asking through genuine ignorance here.
Re:it depends on the size, I think (Score:4, Informative)
Imagine doing this (half-asleep, bear with incorrect/silly git commands):
git pull master
git branch mystuff
Two weeks go by, many, many changes have been made in master, and you do a ton of work in mystuff:
git checkout master
git pull master
git checkout mystuff
git merge master
Or alternately:
git checkout master
git pull master
git merge mystuff
Oh, and in both cases, the merge turns into a single commit without so much as a pointer to the history. You can put that in the commit message yourself, if you like, that's your only option.
That's essentially all you can do with SVN. You don't have the ability to rebase or cherry-pick or otherwise fiddle with your commit history so as to get a clean straight-forward merge in SVN, and because of that merges are slow and usually painful. So while you could regularly merge to keep things sync'd and simple, nobody actually does that in practice. It leads to what many SVN based teams call "merge day" where it literally takes a day to merge in a feature branch and work out all of the conflicts.
The other issue is that branches have to be made on the server and then checked out separately, which makes them expensive. First you're polluting the global history, and second you have to do whatever build environment setup you do once you checkout your branch (you can "switch" your branch over which works in place, but that gets flakey as the things you're switching between diverge - maybe this has been fixed). So for any small-to-mid sized task you're (in practice) going to avoid creating a branch. You'll work right in trunk (master in SVN parlance). You won't make commits as you go, as those go straight to the server where they can never be erased, so your only "oops, undo that" feature you have is the undo buffer in your text editor, or picking and choosing lines from a diff, or sheer memory. And of course you *can't* make that one commit until you've pulled down all the changes that happened since your last update (yes, while your changes are sitting uncommitted in your working files), and those changes get dumped into your working copy as changes, indistinguishable from the code you just typed in diffs (except for conflicts, those get marked in the usual manner)...
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.
Re: (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 [kernel.org]
Re: (Score:2, Informative)
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.
Chances are we never upgraded the server at work, or if we did it was after 2+ years of fearing SVN merges so I never noticed the new features. I've heard others that work with SVN say unflattering things about the automatic merge tracking but I have nothing but their word on that. Maybe they're wrong. I'd given up on SVN's merges long before 1.5 came out, and Git's other features are too compelling to warrant looking back.
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. :\ A single patch is too much, the actual VCS history is too much, so the ideal is offering a doctored up change history?
[...]
Just seems a little superficial to me
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?
The second bit I bolded answers the question you raised in the first. You would clean
Re: (Score:3, Informative)
Trying to explain why git is better than svn is like trying to explain why svn is better than cvs. To someone who has never used it, they simply can't imagine anything better. I've actually been in the position of advocating svn over cvs and been shot down with arguments much the same as you are making now (that cvs has almost everything svn has).
There are a myriad of git commands that do all sorts of useful stuff. mergetool, cherry, rebase -i (interactive), add -i (interactive hunk based add), gitk (for
Re: (Score:2)
Re: (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 m
Re: (Score:2)
I'm working on a small project with 4 people at the moment, and SVN is perfectly fine, and I can't really imagine what I'd do with a distributed version control system (I'd just use it like a centralized one, pushing everything to the one repo everyone pulls from).
it's worth it for local, offline commits even if you're working alone.
Re: (Score:3, Informative)
Re: (Score:2)
Taking a different approach than the other responders, git has an svn gateway so good luck stopping people from using it :)
Re: (Score:2)
Git's SVN gateway is principally useful for migrating projects hosted on subversion to git. The simple fact is that git's change history cannot accurately be represented in subversion, so transformations back and forth between the systems are lossy and painful.
Re: (Score:3, Informative)
isn't centralization the heart of source code management
Not necessarily. Consider a common case:
- Project A works on a significant feature (say a new file system)
- As part of their work, they significantly restructure some related part (say how a fs ties into the kernel) and update other parts of the source to match
- Project B works on a different feature (say overhauling the interrupt thread implementation on SMP systems)
- Project B wants to update the same related parts (say how kernel modules, including file systems, tie into the kernel)
- Project A is alread
Re: (Score:2, Informative)
s/is already done/is already done with the shared part/g
Re:I'd rather seen they moved to Subversion (Score:5, Informative)
We use it at work and it works much better than SVN did.
Apart from everybody's local copies, we keep a repository sitting on a central server. That repo's "master" branch is our release code and, since I'm responsible for the final product, I'm responsible for this branch. Our workflow is fairly simple:
Note that pushing to master doesn't break anybody else, ever, until they decide they're ready to deal with integrating their patch. Nobody ever does the, "Are you gonna commit first or should I?" thing anymore. Developers that are collaborating on a patch sync via a branch on the central server, or directly to each other's machines, or via emailed patches, whatever they want to do. Git doesn't care and neither do I.
It sounds like a lot of tedious work, but Git is just stupid-fast. In the common case the whole update master, rebase, cleanup commits, push cycle takes about as long as SVN used to take to update and then scan for changes and actually commit anything. In the uncommon case where there's a non-trivial merge, the merges tend to come out a lot cleaner since Git is trying to make your changes to the new master one commit at a time, rather than dumping all of the changes in master on top of your stuff (though it can also do that, if you happen to enjoy pain).
And while I prefer the manual approval approach (which scales by appointing trusted lieutenants to take over some of the work) since it keeps me in the loop and keeps everyone else honest, there's no reason you couldn't automate it. Some projects give everyone push access, but disallow anything but fast-forward (trivial nothing-to-merge) pushes to the central server, others I've heard of have people push to a staging branch and a bot on the server grabs the code, runs the test suite, and merges it if it's good. Access is ssh-based, and there are hooks all over the place, you can set up all sorts of schemes when it comes to control of the canonical central repo.
The thing we've found is that because we've all
Or, shorter answer: (Score:2)
svn has one repository, and it's always central. In git, you have any number of repositories, and whether you call one "central" is an administrative question, not a technical one.
It solves the problem of "I don't want to check this into svn yet, but I want to save a checkpoint"; developers can have local repositories for coding, and you'll have one (or more) for integration and release. You can cherry-pick changes, merging any individual change at any time (or never).
And it's ridiculously fast. I never
Re: (Score:2)
Re: (Score:2)
Why wait for a new project? Git and Mercurial both support some bidirectional SVN integration. This means that you can pull changes from the SVN repo, and do your own DCVS thing, then push your commits back to SVN. Your project partner can keep using the SVN repository, and generally doesn't even know that you're trying something new on your end.
Assuming that you're using the conventional SVN project structure, all you need to do is a quick git svn clone --stdlayout file:///path/to/your/repository and you'l
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:I'd rather seen they moved to Subversion (Score:5, Informative)
git makes branching and merging easy enough that the question of "where is the central line?" isn't really an issue- developers can easily work on their own branches without worrying about other branches, and you can still push your developer branch to the central repository so that the question of "Where is this change? Is it in Steve's branch? Do I need to connect to his repository?" is also not an issue- Steve's branch can easily be in the central repository, Steve just needs to push changes in, just like he'd normally need to commit changes. Git's primary difference there is that "Steve's repository" is pretty much just a robust staging area for changes.
However, if you're used to centralized version control, you may miss things switching to git:
- Pick whether you want all or nothing in advance. You can either have "shallow" checkouts, which leave you with a crippled, broken, and useless copy that has no access to history functions, or you can have every change ever made. Once you've made this choice, you can only change your mind by cloning again. There is no way to gracefully get history as it is required.
- This means: no partial checkouts. This is a problem if you're used to versioning large binary files, or have large files which you won't care about for anything other than auditing reasons after a certain time.
- Which also implies: no "modules". This is a problem if you have lots of small related projects, which together make up one massive pool of code. You can have one massive project which everyone uses all of, or you can choose not to track the origin of files which you copy from one project to another. Having a "common" project shared by several others is not possible.
- Unless you try the "submodule" support, which is a broken hack that can devour changes far too easily to trust it to end-users. And submodule support does NOT allow copies from one "submodule" to another, or to your main project. Not while retaining history, anyway.
This is really all one flaw, re-stated five times. Fix this and git will be able to replace any centralized system. Without the change, I can't recommend it to anyone who is involved in a centralized project- at least not when there is a reason for being centralized.
Git is, despite proponent's claims, great for small projects which don't actually need to talk to anyone else and don't need to interface with any other projects. If your project involves other "projects" where the line between one and another is the least bit blurry, avoid git.
Re: (Score:2, Informative)
- This means: no partial checkouts. This is a problem if you're used to versioning large binary files, or have large files which you won't care about for anything other than auditing reasons after a certain time.
Yeah, I agree with this. Git blazes along with the largest of code trees and keeps its history data nice and compact, but it's not so great for binaries. We use git for code and SVN for all our binary data, which is optimal for us as the binaries are unmergeable anyway and we've got workflows in place to deal with that issue.
Having a "common" project shared by several others is not possible.
I'm not sure what the scenario you're thinking of is, submodules have solved this for us.
- Unless you try the "submodule" support, which is a broken hack that can devour changes far too easily to trust it to end-users. And submodule support does NOT allow copies from one "submodule" to another, or to your main project. Not while retaining history, anyway.
Can you elaborate on this? We use submodules at work and we've never had any problem with them (
Re: (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 an
Re:I'd rather seen they moved to Subversion (Score:4, Informative)
There are also advantages to Subversion that Linus states himself [1]. Really the only one of note is that Git isn't so great at having multiple projects in the one repository and the recommendation is to have one per repository and have a super-project that contains pointers to others - which isn't so great a solution.
[1] It was stated in relation to the layout of the KDE repository: http://git.or.cz/gitwiki/LinusTalk200705Transcript [git.or.cz]
Re: (Score:3, Insightful)
that, and exploding checkouts for all users if your repository also contains binary data like media (images, music, videos).
Re: (Score:2)
Really the only one of note is that Git isn't so great at having multiple projects in the one repository [...]
That's plain taking things out of context. KDE organization was named ... stupid? ugly? ... because they in some places have repo for single directory. What is pretty much stupid and ugly.
As well, while Linus mentioned that having many projects in single repo isn't that great, he also mentioned that no practical limit was hit yet. With Linux kernel or imported whole KDE tree, Git still performed better than anything else.
Also note that the speech is quite old - it is more than 1.5 years old. Many thi
Re:I'd rather seen they moved to Subversion (Score:4, Informative)
takes up less space than a Subversion checkout for the same project
Only if you actually *want* the whole project. If on the other side you just want a single file or subdirectory, say in a large gigabyte size repo with graphics, textures and stuff, you have kind of a problem with git. A git clone always downloads the whole thing, svn on the other side allows you do download just what you want, so the download with SVN can easily become a few orders of magnitude smaller then with git.
git could really use a way to do shallow clones so that only those pieces get downloaded that are actually needed, git-clone --depth is a start, but not quite enough.
Re: (Score:2)
Only if you actually *want* the whole project. If on the other side you just want a single file or subdirectory, say in a large gigabyte size repo with graphics, textures and stuff, you have kind of a problem with git.
Yes, Git really isn't great for large, binary data.
Other than that, if you're really only wanting a subdirectory of a project most of the time, maybe it's a good idea to split that subdirectory out into its own project?
But I was just pointing out how ridiculous it is that in repositories full of text, an SVN checkout -- which barely contains any metadata at all, or at least, insists on going to the server for just about anything -- can be as big or bigger than a Git checkout, which contains every version, e
Re: (Score:3, Informative)
You can only split a subdirectory out into its own project if it's not related. If changes ever cross the boundary, you want history. If you just want to point someone to a single place for a checkout, you want the versioning system to have some notion of that.
Meanwhile: Burning a DVD is possibly slower or faster depending on the situation. It's a pretty stupid option either way, though. In this day, any time you're in a situation where using physical media is a better option, you've got a broken protocol.
Re: (Score:2)
If on the other side you just want a single file or subdirectory, say in a large gigabyte size repo with graphics, textures and stuff, you have kind of a problem with git.
As designed. Git is "Source Code Management" system. Please note the magic "Source Code" words.
You shouldn't put in the things you can't diff.
And believe me - you do not want to put such stuff into SVN either. I do not think it was optimized to handle huge binary files. Many commercial systems do optimize blob handing, but believe me, performance anyway degrades quickly so much that you would avoid using the repo at all costs.
P.S. Actually I had in experience in past with SVN and blobs. In one pro
Re: (Score:2)
So you're saying: "Your arguments against using git for these purposes are invalid because git is a poor choice for these purposes"?
Re: (Score:2)
There is no - per definition - good VCS for blobs. That's all I wanted to say.
SVN is suited for it better than Git, yet SVN also performs in some conditions quite bad.
Re: (Score:2, Informative)
You shouldn't put in the things you can't diff.
So all the binary data etc. that is required to build an application should be managed seperately? Our GUI code is generated by a third party tool which stores its information (e.g. fonts) as part of a binary database. This belongs with the source code because the code needs to be modified in step with it. Having the log message is very helpful as it would take hours to work out the changes made between two of these files, because diff isn't useful. The files are 15MB in size.
SVN may not be the best choice
Re: (Score:2)
Unless the revision control system's performance is dreadful I think that all files should be in revision control.
I have to agree. Or rephrasing old saying: a not-checked-in file doesn't exist. (Original by my colleague is "a not-checked-in source code doesn't exist" after several weeks of nightmares trying to reproduce past test case.) Referring to the fact that if file is not under revision control, then you do not have any control over the file.
Or in other words: if you put blobs into SCM, forget about performance.
Mods on crack (Score:3, Insightful)
Re: (Score:2)
Whatever. Tim the Enchanter was a mangy scotch git, and he wasn't weird - was he?
Re: (Score:2)
Re: (Score:2)
Subversion is centralised, based on a single server for the repository, and therefore suitable for corporate use.
What is actually big big lie repeated over and over again. So most think it is true.
Just recall all the pains of branching - and merging (and loosing all revision history from the branch).
Or worse - having no revision control for weeks or months. Since you can't checking unstable code.
I went through all this and frankly I do not see single thing in centralized SCMs which is real prerequisite for corporations. Especially in corporations, where wrapper scripts are routinely used instead of raw tools
Re: (Score:2)
being able to save checkpoints of your own work is NOT the same thing as having decentralized version control. It's just a feature of them.
Properly-managed centralized version control allows anyone to check in at any time.
Properly-written centralized version control software allows anyone to save checkpoints at any time without requiring access to the server.
If git would only allow a centralized model, it would be perfect.
Re: (Score:2)
Git's low-level design is simple enough that I'd say that was okay. It's very easy to grasp.
And then git ate my changes and overwrote a directory I was working on. So, maybe not.
Re: (Score:2, Informative)
If the original perl git packing was done aggressively (which it definitely has been done), then doing an untuned repack can only make it worse.
IOW, the original perl git pack (that you got by cloning a well-packed repository) was probably done with a much larger search window for good delta candidates, and quite likely with a deeper delta chain than the default too. When you did your own aggressive repack, you undid all of that.
End result: normal developers should likely never use "git gc --aggressive". It
Re: (Score:2)
Basically, yes [youtube.com].
Re:Git momentum (Score:5, Informative)
Roughly
Linus was very resistant to version control at all and could always find a reason (or excuse) not to use each version control system that came along.
Eventually someone decided to listen to every demand from linus and create a vcs that met all of them. The catch was it was not FOSS and the gratis version had some pretty obnoxious terms. Things reached a head after someone at OSDL reverse engineered the protocol and linus was basically forced to either scrap bitkeeper or quit his job at OSDL.
However the period with bitkeeper had convinced linus that version control was a good idea. But all the alternatives he could find were either too centralised or too slow. So he hacked together git.
Re: (Score:3, Informative)
Where "reverse engineered" should be translated as "telnetted to the bitkeeper server/port and typed 'help'" [lwn.net]
Re: (Score:2, Informative)
To my knowledge, almost no one besides committers used Perforce to check out the Perl 5 source code. The documentation suggested using an rsync mirror. That's what I did.