Perl Migrates To the Git Version Control System

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."

Comments

que the unreadability jokes

[Dan667]

but this is fantastic. I use perl every day and love it.

Re:que the unreadability jokes

[Dystopian Rebel]

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

[CODiNE]

Qué?

Re:que the unreadability jokes

[Anonymous Coward]

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:que the unreadability jokes

[Anonymous Coward]

What's perl again?

Re:que the unreadability jokes

[Anonymous Coward]

Don't run this script! It popped up a picture of a goatse-tubgirl or a tubgirl-goatse! I don't know what, but I AM SCARRED FOR LIFE AAHHH MY EYES!

Re:que the unreadability jokes

[lordSaurontheGreat]

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

[Anonymous Coward]

Parent post is just gibberish, it is not a real Perl program.

Re:que the unreadability jokes

[hvm2hvm]

well no shit sherlock

Re:que the unreadability jokes

[Anonymous Coward]

If you're going to be pedantic, at least do it right:
ÂQué?

Re:que the unreadability jokes

[Anonymous Coward]

That is pronounced kay and is not a homonym for queue, which is what the GP was pointing out.

Re:que the unreadability jokes

[Anonymous Coward]

FAIL!

Re:que the unreadability jokes

[EddyPearson]

Mod parent up. True slashdotter.

Re:que the unreadability jokes

[DrEasy]

I ran your code and the output was 42.

Re:que the unreadability jokes

[sam_vilain]

Heh, you obviously didn't find any of the actual code used for the pre-historic import, the hostile import, the Raw Perforce Importer or the scarier SQL queries used to manipulate the data. Your program is far easier to understand :-).

Re:que the unreadability jokes

[Anonymous Coward]

That's the combination to my luggage!

Re:que the unreadability jokes

[Anonymous Coward]

Ok, I get the shebang line OK, but the next line looks like you are modifying the contents of the $T variable by substituting instance/s of 'Y9' with the letter 'x', and you have a lot of regex modifiers that I haven't heard of.... 'x' I know, but what are the '0YT-s' modifiers? Oh, I know, this must be that new "perl6" people keep talking about... i haven't learnt that yet. :-)

Oh, and you left the ';' character out in two places before the print statement.... otherwise it looks pretty close to valid perl. :-)

Re:que the unreadability jokes

[windsurfer619]

#! /usr/bin/perl
$| =1;
print "w";
for (1..100){ print "o";}
print "sh!\n";

Re:que the unreadability jokes

[iabervon]

How can you not mention a line that starts "chomp(my $HEAD..."?

Re:que the unreadability jokes

[Anonymous Coward]

Missed one.

Re:que the unreadability jokes

[john.picard]

How in the name of Cleanthe did you get that garbage past Slashdot's shit filter?

Re:que the unreadability jokes

[Anonymous Coward]

Q also appeared on Deep Space 9 in the episode Q-Less.

Re:que the unreadability jokes

[Anonymous Coward]

Oh really?

I'd rather seen they moved to Subversion

[berend botje]

They should have moved to Subversion. Git is just plain weird.

Re:I'd rather seen they moved to Subversion

[Anonymous Coward]

But then there's no benefits.

Re:I'd rather seen they moved to Subversion

[SanityInAnarchy]

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

[Anonymous Coward]

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.

Re:I'd rather seen they moved to Subversion

[kwabbles]

Whatever. Tim the Enchanter was a mangy scotch git, and he wasn't weird - was he?

Re:I'd rather seen they moved to Subversion

[timeOday]

"you're saying they should use a big, slow, central server, as a single point of failure, crippling offline development..."

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

[Anonymous Coward]

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:I'd rather seen they moved to Subversion

[AlecC]

Subversion and git are not really comparable. Subversion is centralised, based on a single server for the repository, and therefore suitable for corporate use. git is decentralised and distributed and therefore more suitable for OSS with distributed developers and no or weak hierarchy, The competitors to git would be Bazaar and Mercurial.

Somebody in my company checked out all three and said that git was the most powerful, but also the most complex, hence a steep learning curve, and had poor Windows support. But presumably Perl developers are not frightened of complex software and unlikely to be using Windows as a primary platform, so git might well be appropriate for them. Bazaar was complemented for being Subversion like and Windows friendly (relevant to my company).

Re:I'd rather seen they moved to Subversion

[abdulla]

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

Re:I'd rather seen they moved to Subversion

[Anonymous Coward]

What an eccentric performance

Re:I'd rather seen they moved to Subversion

[fafne]

There's nothing that suggests that centralized version control and corporate go hand in hand. A common misconception if you ask me, using a DVCS in every day work in a large corporate environment.... or ask sun for that matter. It's absolutely possible to have central release versions with DVCS, it's all about work flow practices.

Re:I'd rather seen they moved to Subversion

[fafne]

DVCS does not mean anti-centralized. DVCS does not introduce arguments between developers, rather ameliorating them as it's easier to try things out and becoming more knowledgeable before discussing issues. It's about how to define the build and release systems. Obviously, you need a 'head revision' or 'release branch' or whatever you want to name the code that's defined as the one version that makes up the product. Having input from different places makes no difference on the release part of the process. Developers move the changes to the release/central build version just like they would with the old model. Almost all resistance I've seen so far is something similar to 'I don't like this because I have to learn something new' obfuscated behind a bunch of misconceptions.

Re:I'd rather seen they moved to Subversion

[eggnet]

Taking a different approach than the other responders, git has an svn gateway so good luck stopping people from using it :)

Re:I'd rather seen they moved to Subversion

[richlv]

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

[grumbel]

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:I'd rather seen they moved to Subversion

[snaz555]

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 already done, and is scheduled to get on the train before project B, so it's natural for B to integrate portions of project A and then track project A's fixes and updates to these portions up to when A integrates into the trunk

This situation is handled very cleanly by distributed systems like git and teamworks. As B selectively merges parts of A it picks up the change log. With svn when you diffpatch across from the A branch to the B branch you lose changelogs, there will be no record that these changes came from A but they'll appear independently in B. When A integrates to trunk if B simply tracks these it will appear as if B edited trunk. This is an inaccurate history. With p4 I get a headache just thinking about it.

Re:I'd rather seen they moved to Subversion

[snaz555]

s/is already done/is already done with the shared part/g

Re:I'd rather seen they moved to Subversion

[BlueCodeWarrior]

Other people have answered, but I feel that Linus can explain things for himself. Linus talks about Git. He discusses how it works with the kernel...even thought it's a bit long, it's pretty good as an intro to the git vs svn argument.

Re:I'd rather seen they moved to Subversion

[n dot l]

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:

1. Developer pulls down a copy of the master branch (this either creates a local copy or brings an existing copy up to date).
2. Developer hacks away, creating, deleting, and merging local branches as is convenient for them.
3. Developer finishes task.
4. Developer pulls down an update, bringing their local master in sync with the central master.
5. Developer git-rebases their code on the new master. What this does is it takes all of the changes they made since their code diverged from the master and applies them to the new master. Git will apply commits one at a time, pausing if it runs into non-trivial merges or anything else that needs to be dealt with by hand. This has proven to be a massive improvement over the old SVN approach of having the updates in trunk blindly dumped on top of your work as the conflicts tend to be smaller, clearer, and much more manageable. Not to mention that the developer who wrote (and understands) the code is doing the merge.
6. Developer tests their code.
7. If the code is bad, goto step 2. Otherwise the dev will collapse their many little "work in progress" commits into a single "feature implemented/bug fixed" commit.
8. Developer pushes their cleaned up commit as a new branch on the central server and alerts me to its presence.
9. I review the diff (practically a nop for trusted senior coders, for the rest, well, I'd be reviewing their stuff anyway).
10. If I don't like it I send it back, else I merge it onto the central master (guaranteed to be a trivial merge since they did the work of rebasing onto the latest code - Git calls these a "fast-forward" and I automatically reject anything that hasn't been properly rebased) and delete their branch from the central server.
11. Developer pulls down new master, deletes temporary local branches, rebases any other work in progress (or puts this step off, up to them, I don't give a damn as long as I get high quality patches in the end).
12. goto 1

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

Re:I'd rather seen they moved to Subversion

[Anonymous Coward]

I think you have to understand how Git works at a lower level in order to use it.

Which would be a complete failure of the tool, if it were true.

Having had a quick look over the tutorial, I'm not sure that it is true though.

Re:I'd rather seen they moved to Subversion

[ThePhilips]

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 things have changed since then.

Re:I'd rather seen they moved to Subversion

[SanityInAnarchy]

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

[Lord Bitman]

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:I'd rather seen they moved to Subversion

[SanityInAnarchy]

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, ever. And even that initial git-clone is likely to be faster, if you have the bandwidth for it -- there seem to be far fewer blocking roundtrips, and far less CPU needed.

The other point of note is that Git seems to have a much lighter, faster wire protocol than SVN. So, if it gets really bad, and your bandwidth really makes it that impractical to do the initial checkout, it might be a valid option to find someone who has a full checkout and have them burn you a DVD. After that, it's going to be less bandwidth to stay up to date, and certainly less to work offline.

Re:I'd rather seen they moved to Subversion

[ThePhilips]

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 project we had single repo for everything: GUI apps, system libraries and home-brew custom OS (what I worked with). In some cases we had to checkout everything and during the process there was one notable file: Visio diagram (~5MB) for GUI application workflow. I wasn't checking how much revisions the diagram had, yet its checkout was taking >30 seconds. At first I thought that svn client/server hanged. Asked my friend whether svn server is alive and by the time he tested svn server, my svn client came back to life.

Re:I'd rather seen they moved to Subversion

[lordSaurontheGreat]

When it comes to learning a "weird" tool, Perl developers are the easiest sell you'll find. Most of them are already command-line literate, and already familiar with source-control doctrine. They're probably thankful they don't have to hunt down annoying proprietary Perforce binaries to do their job anymore.

Git would be inappropriate in situations where you have developers that are either unwilling or incapable of learning how to use the command line and how to manage source control. In that kind of situation, something with a large array of graphical tools, such as Subversion, would be beneficial.

Re:I'd rather seen they moved to Subversion

[ThePhilips]

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. With git you can easily emulate centralized repository - and even more.

As Tom Lord (GNU Arch author; one of the first DVCS) put it: centralized VCS treats its users like second class and gives full power only to few - VCS admins. With DVCS, everybody gets the same power.

With decentralized SCMs, workflow is different and more flexible: you have revision control available all the time independently of what the rest of the company is doing...

Though I see your point now - no more coffee breaks due to server downtimes or lengthy checkouts or check-in ban (due to maintenance or reorganization). Yes, I agree with you completely now. Git is harmful to the corporate culture as a whole by eradicating its very foundation: coffee breaks. [/saracasm]

Re:I'd rather seen they moved to Subversion

[nuttycom]

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:I'd rather seen they moved to Subversion

[n dot l]

- 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 (short of the odd time someone forgets to git submodule update, but the lines in the git status output usually clue people in). What do you mean copying from a submodule to another? You mean like copying between repositories in general, which SVN externals couldn't do any better, or something more specific I've simply not run into?

Re:I'd rather seen they moved to Subversion

[i.of.the.storm]

Thanks for that post, I had been wondering what the excitement about DVCSes for a long time and couldn't really see the point for a while, but your post made it clear. It seems to me that theoretically using a DVCS would be useful even on a 2 person project that I'm doing right now, which we are currently using SVN for. On the other hand though, we rarely touch the same files and we're both on Windows, and Eclipse does have some nice SVN plugins and so does JDeveloper which is what the other guy uses. But I will be sure to give git/hg a look the next time I start a project.

Re:I'd rather seen they moved to Subversion

[tverbeek]

Personally I was hoping they'd switch to wanker or twit, or maybe even arsehole.

Re:I'd rather seen they moved to Subversion

[acidrainx]

There's also a Google Tech Talk video by Linus Torvalds available. It's a little over an hour in length but he gives a pretty good overview of Git's strengths against the more popular version control systems.

Re:I'd rather seen they moved to Subversion

[Lord Bitman]

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. If I don't /want/ 12GB of history for images I'm not using (even if someone else might), I should not have that data at all.

I really think it would be much better and make a lot of people happier if git would just allow a shallow checkout which asked the server for more if needed (and that server can do the same from its origin if it doesn't have it either). Give people the option of setting up servers to do history processing for people who only want a shallow copy for 99% of the work they're doing. And if I want to check out "all history up to version 2.0, but nothing earlier than that", that would likely satisfy absolutely everyone for every day-to-day work anyone ever actually does.

Pulling entire histories is _always_ asking for trouble down the line. Subversion has the fatal flaw of keeping track of everything forever, even if no one wants it anymore (google "svn obliterate" for discussions). git solves this problem by simply not caring about the ramifications, but if the primary repository deems something necessary, EVERYONE gets it. At least with svn the problem is server-side-only.

Re:I'd rather seen they moved to Subversion

[Lord Bitman]

So you're saying: "Your arguments against using git for these purposes are invalid because git is a poor choice for these purposes"?

Re:I'd rather seen they moved to Subversion

[Lord Bitman]

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:I'd rather seen they moved to Subversion

[Lord Bitman]

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:I'd rather seen they moved to Subversion

[NTmatter]

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'll be up and running. You can make your changes, commiting to your local git repository, then just git svn dcommit to push your changes back up to SVN. If it bothers you about uncommitted changes just wrap it up in a git stash; git svn dcommit; git stash pop to store your working copy (eg, your project file, temp files, partially edited config file containing passwords and whatnot) commit and then restore all your extra files. To pull changes from SVN, you just need to git svn rebase to apply your changes to the current head.

Do note that branches and tags aren't propagated back up to SVN if they're created in Git, but that's not such a big deal. You can still merge stuff down into master and push it up to the SVN repo. (There might be a way to get it to work with branches, but I haven't looked at it)

Go give it a try on a private repository. There's plenty of documentation out there (for once), so it's easy to get started. Just beware -- you might like the new workflow.

Re:I'd rather seen they moved to Subversion

[Lord Bitman]

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

[jepaton]

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 for binary data but at least it is possible to put binary data into it. I would rather endure SVN's slowness than have to manually manage binary files. I believe that revision control could be better supported by operating systems. Two copies of every file are managed by a SVN checkout - the base file and the working file. If the filesystem could store these together then the cost would be halved (if the working file referenced the base file until the working file needs to be changed). The SVN tools would then be able to work much faster because the need for file comparison would be less common.

Unless the revision control system's performance is dreadful I think that all files should be in revision control.

Re:I'd rather seen they moved to Subversion

[ThePhilips]

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:I'd rather seen they moved to Subversion

[ThePhilips]

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.

Re:I'd rather seen they moved to Subversion

[ThePhilips]

Properly-managed centralized version control allows anyone to check in at any time.

It doesn't need to be "properly-managed." You can actually do that in SVN already (modulo merging).

You simply have to forget about performance and start getting used to coffee breaks. That's from my personal experience.

And worst case performance of SVN can be really really bad. Colleague of mine updated important headers - and bunch of related files. Everybody got e-mail in the morning and started update. After waiting 30 minutes for svn to finish (normally took ~5minutes) I decided to make my lunch break earlier. Real life story.

Branching in SVN also works. But merges - especially on large project are really nightmare. My past employer actually set sort of record: check-ins were prohibited for two weeks straight so that people can actually check-in fixed results of merge. That's reality of how it works - and you can't make it better in centralized system. Unless of course you can get one of those rare magic wands for your "management."

Properly-written centralized version control software allows anyone to save checkpoints at any time without requiring access to the server.

That's nonsense. The whole point of centralized system that all actions are recorded at central location. (So that they e.g. can be backed up centrally.)

You apparently have no slightest idea what it takes to create your own tag or branch in centralized system - and what kind of performance impact it has on *every user*. But even if we leave performance issue aside, with R&D >50 people you have to be ready for very very serious clashes of tag/branch names. They are all global because they are all in central repository, you know.

That's why pretty much every sane company using centralized SCM have strict rules that only very very few people can create tags/branches.

Centralized systems do not scale on user number. That's pretty much established fact. There is no point to argue on that. But it's not that you had any arguments to begin with (idealistic crap doesn't count). Frankly, I'm also not good in argument department: it's just I worked with CVS/SVN/friends more than 7 years now.

Re:I'd rather seen they moved to Subversion

[PixelSlut]

On the flip side of what you're saying, when you have centralization then you also have to worry about user management and permissions much more.

But with git or bzr you can have a canonical repository up that only a few people have commit access directly into, but as a new developer that won't stop you from hacking on it. You can instantly clone the repo and start working on your own branch, commit all your changes to your own branch, and once it's ready the maintainers can pull you branch and merge into the upstream repo.

In the past there may have been issues like "what if user Foo doesn't have a host to store his or her branches?" But these days we have GitHub and Gitorious, so that isn't really an issue.

Re:I'd rather seen they moved to Subversion

[Zero__Kelvin]

Linus explains it best perhaps. Of course he designed and wrote git (though it is now maintained by Junio C. Hamano) so he would be in a position to do so. Bear in mind that the video is a few years old now, and things have only gotten better.

Re:I'd rather seen they moved to Subversion

[Zero__Kelvin]

"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."

The entry for every commit includes a field for the E-Mail address of the person who did the commit. Not only that but the commits can be pgp signed. So what makes git anything but perfect for a hierarchy of subprojects and parallel projects where everyone needs to be able to communicate with everyone else? That is exactly how the kernel team develops. There is essentially set of separate projects, that are organized into a kind of Meta-project upstream. Maybe I am missing something?

Re:I'd rather seen they moved to Subversion

[AncientPC]

Likewise, Linus also states there are multiple advantages of using git over svn. Most noticeably:

So one of the worst downsides of CVS [and SVN] is _politics_. People, not technology [impede the ease of commits].

He also points out git's advantages in speed and decentralized model.

Re:I'd rather seen they moved to Subversion

[Anonymous Coward]

On Windows. git-svn exists on Windows, but the MD5 implementation is pure interpreted perl, which ends up being extremely slow.

Of course, I just run a Linux VM which is my personal upstream-interfacing tree instead... Works great so far, and the various bits of GUI work better than hg does for me.

Re:I'd rather seen they moved to Subversion

[i.of.the.storm]

I probably will check it out sometime later, maybe within the next two weeks since I'm still on winter break. I hear git is slower on Windows though, and while my laptop has a virtualbox Linux install and a real Linux install, my desktop which I use more right now doesn't want to work with Virtualbox for some reason and I never bothered installing Linux because it was my gaming PC. I've also heard that hg is better on Windows than git so I'll probably play around with that.

Re:I'd rather seen they moved to Subversion

[diamondmagic]

You can only clone the x most recent commits with the --depth option, but it limits what you can do with the repository.

It is possible to rewrite history, delete a file with bad data, or remove a password, etc, using git-filter-branch. It is going to change your commit names, but it can be pulled anyways, git-rebase has some of the details on how to do that. You just have to force a pull if you don't have any local commits, worst case you have to deal with it the same way you do a rebase. (Or maybe you just run the command yourself.)

Put it this way, keeping the history in one place is _always_ asking for trouble down the line.

Re:I'd rather seen they moved to Subversion

[Lord Bitman]

I use SVN and don't keep the history in one place, I only /access/ it from one place. Having history in EVERY copy that accesses it is like copying an entire relational database to every client that accesses it.

using --depth doesn't just "limit" what you can do, it turns git into a retard. Not having the ability to say "hmm, actually, I need that too. Go fetch it." without using low-level operations is brain-dead.

As for "it's possibly to rewrite history", yes, I said that. Git solves the problems involved in rewriting history by ignoring those problems, which I personally think is just fine. The problem is that if you're pulling from some other repository which /hasn't/ decided that the 2GigsOfCachedStatistics folder belongs somewhere else, you can't just tell git not to pull it. Git only operates on an entire deep tree at a time.

This is just the SVN "directory structure is good enough to keep track of any type of change" mentality which Linus calls "brain dead", but.. well, it works, and git doesn't.

All expected to be fixed in a future release, I hope.

Re:I'd rather seen they moved to Subversion

[Anonymous Coward]

You should have a look at git's remote tracking branches. I think they do what you want to here. git-remote(1)

Re:I'd rather seen they moved to Subversion

[Anonymous Coward]

Question,

As I see it the issue at hand is that on your local branch you have several small changes that encompass different parts of the application which are dependent on each other, but each have to be merged separately without the explicit dependencies defined. In subversion this happens with a single dump, in git (if I am understanding it correctly) you are merging into the master each local commit you made one at a time.

However when management decides that a new feature on branch X needs to go out before a new feature on branch Y, and the X merge goes smoothly into the master Z, but the Y merge throws conflicts since it depended on the master being in state Z and not its new state, your going to have issues with the merges using either git or subversion. Thus you still have the problem of developer A deciding with developer B who gets to merge first. I guess I'm not understanding how git solves the issue of merging Y into the master after X was merged into the master since if X changes the master to the extent that the features (api, etc) that Y depended on no longer exist (or their behavior is altered), your still going to have to go back and fix Y before you can merge it into the new master.

Another question (apologies for the rambling post), if git has you performing each of your local commits into the master one at a time (I'm assuming this is how git works, since I don't see how else it could decide to demarcate commits), it seems like this would be harder then subversion's one time dump, unless you were atomically committing working changes into your local branch.

Apologies if I'm just thinking of this from the standpoint of a subversion user and missing the point entirely.

Re:I'd rather seen they moved to Subversion

[TheTurtlesMoves]

Most *source* version control systems do very badly with binary data. Git does better than most, but the repo size gets big as it would with cvs/svn. But hay I just got a second 1T drive for less than 100EU so who cares...

Re:I'd rather seen they moved to Subversion

[Gorshkov]

It seems to me that theoretically using a DVCS would be useful even on a 2 person project that I'm doing right now,

Never mind a 2 person project - I find it VERY usefull for my current one man project. It's an application that has parts for windows, parts for linux, and parts that have to run on both. When I'm running windows, I do my windows work - when in linux, my linux work. Pushing and pulling to and from my file server, where I've got my "master" repositories, makes life soooooo much easier when I'm constantly switching back and forth - I find I don't even have to *think* about where I am on the other platform - I just do my thing for the one I'm on, and what few confilicts I do wind up having are embarassingly trivial to fix.

Re:I'd rather seen they moved to Subversion

[Daengbo]

What I find unbelievable and amazing is that Linux wrote the first version of Git in about a week as just a qick fix to the BitKeeper problem, then Git went on to be a major player in the VSC world. Heck, it may be the leader in DVCSes.

Tech Talk: Linus Torvalds on git: http://www.youtube.com/watch?v=4XpnKHJAok8

Re:I'd rather seen they moved to Subversion

[damg]

Letting repositories sprout like mushrooms is a good thing, it will let your developers experiment with ideas they might have, things that they aren't sure would work yet but they want to try out anyways. In those scenarios, asking for permission and having to create an official branch in the central repo might be too big of a barrier, so they might work on it without the help of any version control which is bad but happens often with centralized VCS, or they'll just drop the idea altogether. And anyways, using something like svn won't stop people from sprouting their own repositories now that we have tools like git-svn which will allow you to clone an svn repo into a local git one.

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.

Re:I'd rather seen they moved to Subversion

[damg]

Git is way better than SVN in pretty much every respect except possibly its lack of slick Windows GUI

And even for those who must have a Windows GUI, TortoiseGit is currently being worked on.

Re:I'd rather seen they moved to Subversion

[richlv]

of course. what i meant - with svn you only get one copy, so a video file that has been replaced 10 times will be N. with git, you would get Nx7 (wild guess at compression capabilities).
inability to checkout partial tree makes this inefficiency worse.

btw, i remember reading about git being able to simulate cvs server for a git repository. would it also be technically feasible to simulate svn server ? that would allow checking out parts of repository with svn for people who wish to do so, and also allow to use svn for binary parts of the repo.

Re:I'd rather seen they moved to Subversion

[Drinking Bleach]

Yeah, of course it'd be technically possible to write a git-svnserver just as there is a git-cvsserver, it's just that nobody has bothered to make one yet. There's also the problem that Subversion is still a moving target, while CVS has been at a stand-still for pretty much a decade or longer... (OpenCVS intends on improving core features after they get perfect compatibility with official CVS, but I'm not sure it'll be of much use to anyone except the OpenBSD team...)

Re:I'd rather seen they moved to Subversion

[Anonymous Coward]

No. The heart of version control is history tracking, especially when parallel lines of development exist and criss-cross. Get that right, and you will be in a surer foot in the road to enlightenment re. version control.

That said, you can use git in a centralized way if you want to. But it can do much better on more complex workflows, which are completely incompatible with second-rate version control systems like CVS and SVN.

Also, if your developers are even in a position to start arguing about who fetches from who, you have MUCH bigger problems to solve, and they have nothing to do with version control systems. Get your teams and workflow properly defined, first!

Re:I'd rather seen they moved to Subversion

[SanityInAnarchy]

If I don't /want/ 12GB of history for images I'm not using (even if someone else might), I should not have that data at all.

Which is why it's not great for binary data.

There are specific reasons why the complete version history is needed -- technical reasons. I'm guessing that the minimum penalty will be, you can't merge with anyone who's made changes against history you don't have.

git solves this problem by simply not caring about the ramifications

No, it solves this problem by making you deal directly with the ramifications.

Specifically, if you want something actually removed from the history, all commits after that point will have to be changed -- they'll have a different SHA -- which will make life hell for anyone who doesn't make the exact same change to their repository.

In other words, if you want something purged from history, the cleanest way I can think of is to tell everyone to run a certain set of commands, with the exact same arguments in the exact same way -- or force everyone to re-clone, which means potentially pulling down that 12 gigs of history again.

Re:I'd rather seen they moved to Subversion

[SanityInAnarchy]

Having history in EVERY copy that accesses it is like copying an entire relational database to every client that accesses it.

I think this is intrinsic to DVCS -- that is, your metaphor is broken. It is not like a client accessing a relational database.

It is like multimaster replication in a relational database.

That is, in part, why Git is so much easier to work with, when your version history isn't big enough to care about the problem you're having. Working with SVN is very much like using a client to a relational database somewhere -- if that database was running on a floppy drive. It really is that bad, frequently -- I can't remember when I've had an SVN command finish in under a second, usually two or three, sometimes twenty or thirty. I can't remember when I've had a Git command finish in over a second, even "expensive" operations like gc.

Now, you're right, it would be very nice for Git to be able to only pull what it needs. In fact, I'm sure this is what it does on disk -- so, here's a brutal hack, which still won't do everything you asked for, but at least matches SVN: Keep your "local" copy on the server, and mount it via a network-accessible filesystem, like NFS or sshfs. Do the initial clone/branch over ssh, so that you get a hardlink'd copy. And I'm not sure if it's supported, but you should be able to just do it for the .git folder, so that your working copy is local.

That said, both of them are equally brain-dead in the ways in which they're brain dead. But working on source code, in a textual format, I tend to run into SVN's limitations on a daily basis -- in fact, I'd be lucky if an hour went by when I wasn't fighting with it. At least, that's how it used to be. Now, with Git, I tend to run into your particular limitation... never.

Re:I'd rather seen they moved to Subversion

[SanityInAnarchy]

Also, for what it's worth:

any time you're in a situation where using physical media is a better option, you've got a broken protocol.

Or you're trying to make it do something it wasn't designed for. Or it actually does need that bandwidth.

Maybe not in the case of Git, but consider what you've just said: If I want to download, say, two or three hours of 1080p video, that's going to take some time. If I'm on dialup, physical media is very likely a real solution, especially if I need more than one.

Re:I'd rather seen they moved to Subversion

[Anonymous Coward]

Only if you care for the Windows crowd, which is the one place where using git ain't always a picnic, even if it is getting better by the day.

Why would the perl hackers bother with that, I don't know. Nor did they, so they didn't.

Re:I'd rather seen they moved to Subversion

[SanityInAnarchy]

Git would be inappropriate in situations where you have developers that are either unwilling or incapable of learning how to use the command line and how to manage source control. In that kind of situation...

...you should fire them and hire competent developers.

Not wanting to use the commandline is one thing. It's somewhat understandable, and tools are being developed.

But not wanting to learn how to manage source control? That's as bad as a programmer who doesn't know how to use a text editor, and instead either dictates, or writes code in Word, or writes it by hand and uses OCR...

You think I'm joking, but quite a lot of these stories are about people who didn't want to learn how to use version control (search for "developmestruction"), and at least a couple are about abominations apparently written for programmers who can't or won't use a text editor (and yes, someone actually did write code in Word, using things like font color instead of curly braces).

Re:I'd rather seen they moved to Subversion

[nategoose]

Centralization can be considered the heart of release management, but not source code management.
Project lead gets to say what is a release. That release is from his own repository, and he decides what other changes from other repositories are in it.
It's a really easy way for someone play around with the project without bothering the project leadership with the changes unless they decide to share it.
When it is shared it's easy enough to ignore those changes or accept them.

Re:I'd rather seen they moved to Subversion

[n dot l]

As I see it the issue at hand is that on your local branch you have several small changes that encompass different parts of the application which are dependent on each other, but each have to be merged separately without the explicit dependencies defined. In subversion this happens with a single dump, in git (if I am understanding it correctly) you are merging into the master each local commit you made one at a time.

However when management decides that a new feature on branch X needs to go out before a new feature on branch Y, and the X merge goes smoothly into the master Z...

To your first question, I would have the committer rewrite their local history to give me several fairly stand-alone commits rather than a mess of "work in progress" commits or a single "three days work" commit. I don't really allow anything else into the main release codebase. If things have to be shuffled around after that, yes, there are going to be merging issues, there would be with any system. Git has some nice features, however, that make dealing with merge issues like that much easier, provided you've taken the time to keep the main history sane.

Another question (apologies for the rambling post), if git has you performing each of your local commits into the master one at a time (I'm assuming this is how git works, since I don't see how else it could decide to demarcate commits), it seems like this would be harder then subversion's one time dump, unless you were atomically committing working changes into your local branch.

Git has no requirements whatsoever when it comes to development practices. I have commits going into the master one at a time for my own sanity. The old SVN "pull down master, push up my changes" style will work just as well with Git as with anything else. In fact, that's what we do, except that pulling and pushing from master is less disruptive to people who aren't yet ready to merge, and I have people submit patches with clean histories (which make merging both now and later easier) rather than SVN's "here's some changes on top of your work, hope that works for you" approach.

As for merging branches that have diverged quite a bit, again, I leave that up to the developer of the branch. If they want to periodically rebase their stuff (covers merging in master + cleaning up history), they're free to do so. Or they can do it all at once before they give me a patch. My requirements are simply that their stuff go in as a small number of well-organized patches on top of the current master. Beyond that they can do as they please.

Re:I'd rather seen they moved to Subversion

[Lord Bitman]

remote tracking branches are just branches which are easy to pull someone else's change into. This has nothing to do with sharing changes between different projects, sub-projects, etc. The "master" branch, unless I've gotten my terminology mixed up, is often a remote-tracking branch. ie: It's a thing you almost can't avoid using regularly in git anyway. It is unrelated to any post I have made on the subject, other than being the place where some of the features I yearn for would need to be added.

Re:I'd rather seen they moved to Subversion

[Lord Bitman]

Git is like multimaster replication of a database, yeah. But in this example that's used as an alternative to /transactions/.

And it's not just a matter of "big enough", but basic organization. Would you rather tell someone who asks "where can I find this project?":
  - this url: svn+ssh://path/to/repos/path/within/repos/foo; and that's all
  - or, this url: ssh://path/to/master; "And within that you want the "foobar" directory. It'll be in there along with every other project that uses libfoo, since that's the only way to share things with libfoo and other projects when using git."
  - or, this url: ssh://path/to/masterfoobar; and this one: ssh://path/to/masterlibfoo; and instructions on how to set them up manually

I understand "well then, don't do that!", but this pretty much just assumes that nobody will ever want two things, or not already be familiar with one thing, or that everybody /likes/ setting up PATH variables.

Your idea of a "brutal hack to do what svn does" would.. not at all do what svn does. I'm guessing you work only in a "/SingleProjectInARepos/{trunk,branches}" environment, and have never had to deal with maintaining a large repository which is useful to more than one person and useful to more than one person at a time.

I've been annoyed with svn's limitations before. A lot. I've in two jobs been in charge of maintaining SVN repositories, and /often/ wish that git were an option. But it just wasn't, for either. On one, due mainly to the limited (and various) systems we were working on. But I find it strangely coincidental that events conspired to put me in two situations where these needs, for whatever reason, existed. SVN was not ideal, and needed a lot of help to keep it going.

BUT: It could be made to work. It had ways worked out of doing what I needed to do, by people who were smarter than me. That information could be found online easily. Subversion's difficulties often amounted to needing to write good commit messages. When SVN failed due to my own fuck-ups, it did so in a way which hurt no one, and was easily restored.

Git is apparently not mature enough to have these things worked out yet. When git fails, it can need arcane magicks to get it working right.

And because git encourages you to keep your "working" branches local, fucking up your local repository can mean a serious headache.

And I can go on and on, but I've done that already.

Re:I'd rather seen they moved to Subversion

[lordSaurontheGreat]

A bunch of friends and I want to build a video game. I'm the only programmer. The rest are talented artists and musicians. They aren't computer scientists, and hence are almost completely foreign to the command line. I use Subversion because it has TortoiseSVN, which is difficult enough for them to learn to use.

Not everyone is a bash-tested, Linux-wielding Level 99 Code Mage, and successful software keeps this fact in mind.

Had I the money, I'd pay for Perforce because it's far easier to use than Subversion for the reason that it's targeted towards teams that also have people that aren't coders. I don't, so Subversion was the runner up.

When working with other people, you can't pick software because it's just better, you have to pick software because it's what the users can use. IOW, ask not what software you can learn to use, but what software your friends can use with minimal effort and still get the job done!

Re:I'd rather seen they moved to Subversion

[SanityInAnarchy]

The rest are talented artists and musicians.

Deal with the assets separately, then. SVN might even be a good fit for that, and I believe Photoshop has something like version control built-in.

Or, maybe: When they've finished something, take the output -- the actual PNGs (or whatever you're using) -- and put those into version control. Manage the source Photoshop files with something like Time Machine.

Not everyone is a bash-tested, Linux-wielding Level 99 Code Mage, and successful software keeps this fact in mind.

No, but if you're going to be working on the software, as implied by "developer", learning to use version control is essential. Again, not knowing how to use that is like not knowing how to use a text editor, or your artists not knowing Photoshop.

And for what it's worth, everyone who builds creative works should find some VCS and learn it. If they have to collaborate, they should learn it well.

Re:I'd rather seen they moved to Subversion

[SanityInAnarchy]

in this example that's used as an alternative to /transactions/.

Because for the scenarios Git was designed for, transactions aren't enough.

Would you rather tell someone who asks "where can I find this project?":
      - this url: svn+ssh://path/to/repos/path/within/repos/foo; and that's all
      - or, this url: ssh://path/to/master; "And within that you want the "foobar" directory.

It'll be in there along with every other project that uses libfoo, since that's the only way to share things with libfoo and other projects when using git."

Or, you can use submodules. Problem solved!

Your idea of a "brutal hack to do what svn does" would.. not at all do what svn does.

You're right. It would use less disk space, and likely be more bandwidth-efficient. And I was talking about the specific problem you were having -- that you couldn't do a shallow checkout.

Subversion's difficulties often amounted to needing to write good commit messages. When SVN failed due to my own fuck-ups, it did so in a way which hurt no one, and was easily restored.

"Easily restored" is a property of any good VCS. But no matter how descriptive my commit messages, that doesn't help with the fact that a simple merge, which would complete in under a second in Git and likely have no conflicts, will take half an hour in SVN and have tons of conflicts.

The only solution is to go back to SVN 1.4, or find the magical flags that make 1.5 behave like 1.4. Then, I can put revision numbers in my commits, and have to stare at the logs for two minutes before every merge, and the merge is still going to take another minute or two.

Keep in mind -- these were on the same repository.

It didn't import into git-svn properly, for what that's worth -- I had some namespaced tags (that is, tags/foo/1.2.3), which meant I had one "tag" called "tags/foo". That made the repo much bigger than it needed to be, but still usually smaller than an SVN checkout, and still much faster to work with.

When git fails, it can need arcane magicks to get it working right.

Same is true of SVN, IMO. The difference is how frequently SVN fails, compared to Git.

And because git encourages you to keep your "working" branches local, fucking up your local repository can mean a serious headache.

Nothing stopping you from pushing your working branch, if you want others to see it. If you don't, backup is still trivial. About to do something that you're afraid will screw up the repository?

git-clone my-project my-project-backup

Hardlinked, so that will take almost no time, but if you screw it up, you're safe. Want to protect against disk failure? Clone to another drive, or another server (anything with an SSH account will do). Don't know when you're about to screw it up? Write a cron job.

It's called "backup", and it's something you have to do with SVN also. The difference is, SVN encourages you to commit less often (because commits are slow, and you can't rewrite history), so you still keep stuff local. Only now, to back up your local copy, you need this:

cp -a my-project my-project-backup

And the server also needs to be backed up -- unlike Git, if the server implodes, all your history is gone, forever, and it'll take a lot more work to start over from everyone's working copies.

Re:I'd rather seen they moved to Subversion

[lordSaurontheGreat]

Dealing with the assets separately is problematic - some of us are out of state, other out of country. Subversion is kind of like an advanced FTP to them which has the ability to keep a record of everything that's happened.

I agree, people should learn version control theory and one VCS, but this is not a perfect world, so I dealt with it with the tools and resources available to me.

Re:I'd rather seen they moved to Subversion

[nuttycom]

Apparently you haven't been introduced to the 'git submodule' command? You can add modules (recursively) at any point in your source hierarchy. Such modules are entirely independent git repositories; all that's tracked in your base repo is the version of the checked-out modules.

Re:I'd rather seen they moved to Subversion

[TheTurtlesMoves]

really. I thought in svn there would still a version of each binary in there somewhere. I mean what good would it be if it didn't?

Re:I'd rather seen they moved to Subversion

[richlv]

obviously !
in the central server :)
so yes, server has to keep all these versions, but all your users do not have to. if you have only one or two users, that might not matter much, but if you expect your users to become testers and contributors, you don't want the repository checkout size make them running screaming away.

Re:I'd rather seen they moved to Subversion

[^BR]

In that transcript Linus Torvald told

A lot of people assume since git uses SHA-1 and SHA-1 is used for cryptographically secure stuff, they think that it's a huge security feature. It has nothing at all to do with security, it's just the best hash you can get.

Lulz, well no, frightening actually.

Re:I'd rather seen they moved to Subversion

[TheTurtlesMoves]

Oh i see. When i was using svn and cvs i would rsync the repo locally anyway. But now I understand.

Re:I'd rather seen they moved to Subversion

[Lord Bitman]

Or, you can use submodules. Problem solved!

Two points:
  - Can I copy from one module to another while retaining relationships and history? I can in svn (as long as it's not an external) since svn doesn't care what you declare to be a "module".

  - Last I checked, Submodules are broken to the point of being worse than svn:externals. A simple note in a wiki page for using submodules says, as if it didn't matter: "It's not safe to run "git submodule update" if you've made changes within a submodule. They will be silently overwritten". In my book that makes submodules unsuitable for any purpose. When I last investigated this problem it seemed that submodules were still considered to be in "dirty hack" status, and haven't yet been fully integrated into git.

Other points in your post, like claiming that editing directly on a remote share uses less bandwidth than sending periodic diffs, or that "don't worry, we all have a copy somewhere" is a valid backup strategy for a business, were ignored.

Re:I'd rather seen they moved to Subversion

[ukyoCE]

Thanks for this post. The description as "distributed" is I think the most confusing part. But as long as there's still an authoritative repository somewhere that's official and controlled, it doesn't sound like an issue.

I think "merge day" syndrome with SVN usually comes from people using project branches incorrectly. We got pretty involved in branching and merging at a past employer. Doing this:

Trunk -> branch -> project A
project A changes a bunch
Trunk changes a bunch (project B finishes and merges in)
project A -> merge -> Trunk

Is wrong. Other people were working in the trunk in the meantime, and now everything is very different. What you SHOULD do with SVN is:

Trunk -> branch -> Project A
trunk changes -> merge -> Project A
(this should be done weekly or so ideally, but most importantly is done before merging A back in)
Project A -> replace -> Trunk

You can call it a merge at the end, but since your project has all of the trunk changes, it's the same thing as replacing the trunk.

Anyway, that was working quite well for us, but I think is a lot more involved than most teams get with SVN. And it sounds like GIT helps a ton, especially if it stops to resolve conflicts incrementally, rather than applying all changes as a single massive changeset like SVN does when merging.

Re:I'd rather seen they moved to Subversion

[SanityInAnarchy]

Can I copy from one module to another while retaining relationships and history? I can in svn (as long as it's not an external) since svn doesn't care what you declare to be a "module".

A submodule is an entirely separate project. So you can port the entire history over (with rebase), but you probably don't want to.

And these are, in fact, the equivalent of svn externals.

"It's not safe to run "git submodule update" if you've made changes within a submodule. They will be silently overwritten".

Whereas with SVN externals, it's not really safe to run 'svn update', just like with the rest of SVN, if you've made changes. Your changes may not be silently discarded, but your working copy could easily get so completely screwed up that it's faster to start over.

Oh, and you quoted that out of context. All that's needed is to check out a branch first.

Even if they are overwritten, unless you've run 'git gc', it's probably possible to recover. Contrast this with svn -- there is no way to undo an 'svn revert'.

And on top of all of that, updating the submodule wasn't really a common operation. Just as you might freeze to a specific version of a library, you probably wouldn't update the submodule very often.

Other points in your post, like claiming that editing directly on a remote share uses less bandwidth than sending periodic diffs

Again, only for the .git folder. Given that git does store periodic diffs, I don't see the difference.

Oh, wait, yes I do -- when I run 'svn merge', there's a good chance svn 1.5 will dig back through several months worth of history, reading some sort of metadata from each, wasting bandwidth, time, and CPU. And a half hour later, I might have something merged, or I might have a pile of conflicts to settle, and I might have to start the process over from scratch again.

"don't worry, we all have a copy somewhere" is a valid backup strategy for a business

I'm sorry, every workstation, plus the production servers if you use Git for deployment, will have a complete copy. Please explain how that's not a valid backup strategy.

Re:I'd rather seen they moved to Subversion

[Anonymous Coward]

Uh.. except it's only faster for a very small set of files. Linus himself said git is only really useful for projects about the size of the Linux kernel. Why do you think the KDE project's attempt to switch to git failed so spectacularly? Why do you think Google didn't move over wholesale after Linus' half-drunken tirade.. er sorry talk?

This must be the sign

[berend botje]

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!

Re:This must be the sign

[winkydink]

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:This must be the sign

[Anonymous Coward]

It's coming with the Hurd kernel. Oh yes, that means never. No one cares about PERL anymore. Apart from a few crusty admins that think they can be developers.

Re:This must be the sign

[CarpetShark]

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

Re:This must be the sign

[VGPowerlord]

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

Re:This must be the sign

[Anonymous Coward]

what do you mean? I'm running perl 6 now. The question you should be asking is *which* perl6 am I running? There's two of them.
Rakudo Perl 6 (runs on a VM called parrot, which is itself at least partly written in perl6).
Pugs Perl 6 ( written in Haskel ).

Re:This must be the sign

[jonaskoelker]

2009: the year of perl6 on the desktop! ... Or how about:

Yeah, I hear they're going to use perl6 for the next rewrite of DNF.

Re:This must be the sign

[dorward]

I wouldn't hold my breath on Perl 6, but progress is being made there.

The biggest problem with it, IMO, is that it masks all the work being done on Perl 5. It wasn't that long ago that Perl 5.10 was released with some nice new features (including chained file test operators and the // operator).

Darcs vs. Git

[jbolden]

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

[SanityInAnarchy]

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:Darcs vs. Git

[Johnny Loves Linux]

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]
2. Comparisons: http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation [haskell.org]

Re:Darcs vs. Git

[Anonymous Coward]

Actually, you might not know this, but the Haskell folks already moved over to git from darcs a while ago.

There's no unified group called "the Haskell folks", any more than there is "the C folks". The GHC team decided to switch to git, but there are still plenty of Haskell users who like darcs.

Re:Darcs vs. Git

[r7]

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), 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...

Re:Darcs vs. Git

[jbolden]

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!

Re:Darcs vs. Git

[n dot l]

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 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.

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

[SanityInAnarchy]

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:Darcs vs. Git

[doom]

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.

Re:Darcs vs. Git

[ComputerSlicer23]

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 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.

Re:Darcs vs. Git

[imbaczek]

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.

Re:Darcs vs. Git

[this great guy]

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

[this great guy]

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

[n dot l]

I remember seeing some sort of simple incrementing revision/commit number. It was a while ago and I'm tired now, so maybe I'm just confused or misremembering. Apologies if I've spread misinformation (and someone mod parent up if that's the case).

Re:Darcs vs. Git

[this great guy]

The incrementing number you are referring to is the revision number, which is just an alias for the SHA1-based revision ID. It is unique to each repo (so can get "out of sync" as you say) and exists merely for convenience for the developer working with a given repo.

Re:Darcs vs. Git

[Anonymous Coward]

hg actually has both. The incrementing revision number is useful for referring to changesets in your own local repo, but as you said, useless for sharing with others.

Mercurial always shows both the incrementing integer and the hash alongside each other and will accept either for any commands that require a revision to be input.

Re:Darcs vs. Git

[Anonymous Coward]

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.

And how many of those are good?

Re:Darcs vs. Git

[Anonymous Coward]

that seems to mean that the GHC feature set isn't good enough for large applications.

You mean the Darcs feature set? :)

Re:Darcs vs. Git

[Anonymous Coward]

There's no unified group called "the Haskell folks",

Yes there is. Haskell was designed by committee -- by members of the FPLCA, under the auspices of the FPLCA. It was intended to merge research-related features found in other functional languages (static typing, type inference via Hindley-Milnor, etc), and to provide a lingua franca for research. And GHC is the reference implementation, produced under the auspices of the FPLCA.

http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/history.pdf

Re:Darcs vs. Git

[r7]

Mercurial makes it harder for you to do something "bad" like re-write history too far

I've always considered history re-writing to be a black hat's dream and a manager's nightmare. What, if any, are the benefits to history re-writing?

Re:Darcs vs. Git

[ComputerSlicer23]

All of the history is cryptographically signed, so nobody can re-write history without everyone else noticing. Unless there is precisely one copy of the history.

Imagine that you have v2.3.1, and you want to write feature v2.3.1 + FooFeature. In my experience, it is best to write "FooFeature" as a series of small self contained patches that move from the base, towards implementing FooFeature. For now, let us say that FooFeature will take 4 patches for the sake of argument. We'll call them Foo1, Foo2, Foo3, Foo4. I go implement this feature, and publish it out to a repository of mine in a branch called "FooFeature-branch".

I publish it to my personal repository. You go review it, and you tell me that I have one flaw in each patch. So I have two choices:

• Implement Foo5 fixing the 4 flaws.
• Modify the four patches generating Foo1', Foo2', Foo3', Foo4'.

Historically are you interested in having 4 perfect patches, or 5 patches, 4 of which are flawed? I prefer having 4 really solid patches, rather then fixing all the flaws in a fifth. In Hg, you can use Mercurial to accomplish this, but it's hard to do once you publish. With git, it's trivial... Search for git rebase --interactive to find people talking about the wonders of it. It's also useful to linearize your history. Doing this is makes all of the concurrent work look like it was done sequentially. That's a good thing when you go to use bisect functionality to search for a bug. You cannot do that in hg, which means using hg bisect is less likely to zone in on an error when doing lots of concurrent development.

In the end, the rule is, you never re-write history once it's published to a "public" repository. I use it all the time, while developing features in my personal repository.

Kirby

Re:Darcs vs. Git

[jbolden]

Yes I meant the Darcs feature set. GHC has worked for large applications, though there are some problems there as well.

Re:Darcs vs. Git

[thetorpedodog]

As a comparatively new Hg user, I can't address all of these criticisms, but I can tell you that the Mercurial revision number is not the canonical identifier, in fact it is the SHA hash. The revision number is just a quick shortcut so you can remember revisions easily in the short term, and can be messed up by merges.

Re:Darcs vs. Git

[SanityInAnarchy]

Quite a lot of them, actually, for the specific thing you're wanting to do right now.

In fact, the official Git book isn't bad, either.

Re:Darcs vs. Git

[bcrowell]

Darcs has some cool and unique ideas in it. E.g., you can rename a function that's referred to in every file in your project, and that renaming becomes a patch. That patch can then be applied either before or after other patches, and it doesn't matter whether the people who did the other patches were working with versions that had already had the rename patch applied. It's a shame that the shortcomings in Darcs's implementation are getting in the way of letting people enjoy that kind of functionality. One can hope that the ideas will eventually be implemented in other RCSs.

Re:Darcs vs. Git

[sudog]

The Linux kernel isn't a big project. A few tens of thousands of files and a few hundred MB? That's "big" to you?

Let's fast-forward a few more years.. development project sizes rise, amount of data rises, number of files rise. Are you trusting that git will be reprogrammed to be able to scale to such sizes? KDE tried to migrate to git, and all their sub-projects are internally dependent on one another. Therefore it wouldn't be feasible to expect them to migrate to multiple git repositories. And that attempt failed. My point is that git doesn't scale. It goes up to size X, and beyond that it simply fails.

In other news

[Anonymous Coward]

Some perl users use emacs, others use vi.

Slow news day, eh?

But... is Perl now historical only?

[Slartibartfast]

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?

[berend botje]

I take it you have volunteered to help finish P6?

Re:But... is Perl now historical only?

[Anonymous Coward]

maybe he is a java developer

Re:But... is Perl now historical only?

[SanityInAnarchy]

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 released when it's done, not before. For a good example of what happens when people release something just to release it, look at KDE4.

Re:But... is Perl now historical only?

[WWWWolf]

When it's released, Perl 6 is going to be sweet and innovative and a real contender when compared to Ruby.

Meanwhile, Perl 5 isn't going anywhere just yet, and it still has its place in the toolbox. I personally use it for problems that are too complex to be implemented as shell scripts but not complex enough to warrant a nice object-oriented approach (that'd be Ruby's turf) or need GUIs and somewhat effortless non-*nix deployment (for that, there's always Java). Perl 5 is still very nice if you want some powerful text processing done. for example.

Re:But... is Perl now historical only?

[Anonymous Coward]

github? What's the point of a decentralized VCS if you're just going to centralize it?

Re:But... is Perl now historical only?

[Anonymous Coward]

"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? "

I haven't been modded troll in a long time, but here we go:

Perhaps instead of spending a year futzing around with source repositories (and who wants to bet it was really more like 1.5 - 2 years?), maybe they should focus on developing Perl 6? Perhaps this was something done by bored Perl sys admins with nothing to do and not core Perl developers (though it's hard to imagine them not being affected by a source code migration).

Re:But... is Perl now historical only?

[Anonymous Coward]

Perhaps instead of spending a year futzing around with source repositories (and who wants to bet it was really more like 1.5 - 2 years?), maybe they should focus on developing Perl 6? Perhaps this was something done by bored Perl sys admins with nothing to do and not core Perl developers (though it's hard to imagine them not being affected by a source code migration).

Perhaps you have absolutely zero knowledge about how Perl is developed?

Re:But... is Perl now historical only?

[jbolden]

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?

[Anonymous Coward]

I take it you have volunteered to help finish P6?

Perhaps you've read Mythical Man Month?

Re:But... is Perl now historical only?

[thanasakis]

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:But... is Perl now historical only?

[BlueCodeWarrior]

The release still has to come from somewhere. The idea is that you let GitHub become the repo where everyone starts from. Only the lead maintainer (or whoever) actually has access. He only merges that repo with his. He only merges his repo with the ones of the leads for each major section of the project. They only merge changes with people who are working on their section...etc. Think pyramid. This is how Linux is handled.

Re:But... is Perl now historical only?

[tabrisnet]

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 vs perl5 code and migrate an old perl5 project over.

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.

I would have the same problem writing my apps for perl5.10, as perl 5.8 is still in CentOS 4 and CentOS 5 (and let's not forget Debian stable [etch] or SuSE Linux Enterprise Server 10).

Re:But... is Perl now historical only?

[Leynos]

Duke Nukem Forever is written in Perl 6. There's your answer.

Re:But... is Perl now historical only?

[jadavis]

"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:But... is Perl now historical only?

[thue]

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, which began development in 1990 and is still not production ready...

Re:But... is Perl now historical only?

[berend botje]

If you are referring to the old maxim that adding more developers won't speed up the project but actually delay it, I would like you to reflect on the fact that removing too many developers won't get the project done either.

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.

Re:But... is Perl now historical only?

[SanityInAnarchy]

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 me wrong, I plan to roll my own anyway. But even then, I see no reason not to also mirror it on Github, since it's so trivial to maintain multiple repositories.

Re:But... is Perl now historical only?

[SanityInAnarchy]

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:But... is Perl now historical only?

[Anonymous Coward]

Agile/XP is all about designing piece by piece and redesigning as necessary, instead of planning every little detail from the get go. If you're creating a programming language, the essential syntax is obviously something that needs to be considered as a whole, and which you want to fundamentally alter very rarely, lest you break zillions of already-written programs. The *implementation* is less important and far more malleable. What I'm trying to say is that there's nothing wrong with agile programming methods, though as with anything else in the world, some of its proponents are fools. It just needs to be applied prudently. Sitting down and hacking out code without planning isn't good programming practice, period.

Re:But... is Perl now historical only?

[chromatic]

If you just want [Perl 6] you can use it today with Pugs. That is the "release often" and it finished.

I'm not sure how you apply "release often" to Pugs.

If you want a real release candidate the problem is Parrot.

The twenty-fifth stable monthly release of Parrot in a row will occur on 20 January 2009. This includes, by my reckoning, the 13th stable monthly release of Rakudo in a row.

There is no guarantee these problems will get solved.

Besides past results, no -- but what other guarantee will you get anywhere else?

Re:But... is Perl now historical only?

[chromatic]

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.

Can you name multiple agile advocates who've actually produced software who argue that design is not a part of agile development?

What about other design projects, like building a bridge?

There's a huge difference. We call software software because it's not hardware. We don't call bridges software because they're not software.

Re:But... is Perl now historical only?

[jadavis]

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

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 counterproductive due to some misdesign.

In this specific case, the above property (cited from wikipedia) is impossible to meet, because it's impossible to deliver useful software rapidly (just like with a bridge). Thus, in this specific case, agile development may not be a wise approach.

Of course, in many cases, it's very possible to deliver useful software rapidly. For those cases, agile development may be great.

There's a huge difference.

Everything is a little bit the same as everything else, and a little bit different. I was making an analogy between bridge building and designing a language. Both are platforms, and both require up-front design. I think my analogy is apt.

Re:But... is Perl now historical only?

[jadavis]

And here's the smoking gun, right on the same referenced wikipedia article:

"Agile chooses to do things in small increments with minimal planning, rather than long-term planning. Iterations are short time frames (known as 'timeboxes') which typically last from one to four weeks." -- http://en.wikipedia.org/wiki/Agile_development

"Minimal planning" is not well-suited to the development of a new platform of any kind. Case closed.

Re:But... is Perl now historical only?

[chromatic]

I'm not going to dig through people's blogs, but here's a wikipedia quotation:

I asked for a quote that suggested that there's no design in agile development. You're certainly welcome to read as much into a quote as you like, but such a claim needs stronger supporting evidence. Here's your strawman argument:

If you deliver a platform (be it a bridge or a programming language) before the design is complete....

Every iteration builds on the whole, so that the whole is not complete until the final iteration, but each iteration should be self-contained and complete enough that its design is complete -- otherwise you won't know what you need to produce, and you won't be able to deliver that iteration.

Re:But... is Perl now historical only?

[jadavis]

I asked for a quote that suggested that there's no design in agile development.

You think "minimal planning" (as I cited in my follow-up comment) and "rapid, continuous delivery" can be compatible with adequate design for a major platform?

each iteration should be self-contained and complete enough that its design is complete

But how do you know that the small thing you produce actually fits into a coherent overall design, if no such overall design has been completed?

I am arguing that there are some problems for which nothing useful can be delivered for an extended period of time -- time which is needed for complete, coherent design. That extended period of time during which nothing is delivered does not look like "agile development" to me, and it does not appear compatible with the wikipedia definition.

Re:But... is Perl now historical only?

[chromatic]

You think "minimal planning" (as I cited in my follow-up comment) and "rapid, continuous delivery" can be compatible with adequate design for a major platform?

I believe that necessary and sufficient planning and iterative delivery are compatible with adequate design for a major platform. Our velocity developing Perl 6 increased dramatically when we started working this way.

... it does not appear compatible with the wikipedia definition.

I don't take Wikipedia citations seriously in debates.

Re:But... is Perl now historical only?

[jbolden]

In terms of release often Pugs has been producing versions of Perl.

As for Parrot the problem is not that Parrot is not open source but that it is very very behind schedule. Feb 2001 Conway gets a grant to get Parrot finished. Supposedly 1.0 of Parrot is out in March of 2009.

As for the reasons for skeptical there were serious problems with the much easier Python implementation. Perl 6 is very innovative, Python is much more innovative. They are making progress but so far they have not gotten through all the road blocks by any stretch. This might have been too much of a leap. I hope not, Perl is still my second favorite language.

Re:But... is Perl now historical only?

[chromatic]

In terms of release often Pugs has been producing versions of Perl.

If Pugs has had a release in the past two years, that's news to me. The most recent release on the CPAN is from October 2006. Since then, Parrot has had at least 25 stable monthly releases.

Feb 2001 Conway gets a grant to get Parrot finished.

Damian has never worked on Parrot -- and the name Parrot didn't even exist until April 2001.

As for the reasons for skeptical there were serious problems with the much easier Python implementation.

Indeed there were. Parrot wasn't stable. The architect disappeared for six months. There was no PCT. The code was a mess, thanks in part to the Piethon contest. Parrot lost a couple of years due to that mess.

They are making progress but so far they have not gotten through all the road blocks by any stretch.

Please feel free to update the Parrot wiki with a list of the outstanding roadblocks, if we haven't already listed them.

Re:But... is Perl now historical only?

[tabrisnet]

a) Most of my work is in spaces where enterprise distributions are much more likely to be present. And despite Shuttleworth's aspirations, Ubuntu isn't particularly enterprise-worthy (Google has been learning that lesson the hard way with their Goobuntu project).
b) Lack of CPAN modules is easy to overcome if the module doesn't use XS. just distribute the necessary modules yourself. If the module does use XS, but you can use a version a year or 2 old you can instruct the user how to install the relevant RPMs.

I cannot however rely on the old version of pugs to be sufficient. Plus, the bytecode compiled form doesn't mean it's usable w/o the relevant runtime engine...

Any of these solutions requires a stable implementation to rely on.

Re:But... is Perl now historical only?

[jadavis]

I don't take Wikipedia citations seriously in debates.

OK, then perhaps our only real difference is in the definition of "agile". Whoever wrote the wikipedia article apparently defines it differently from you (using words like "rapid" and "minimal planning").

You can enlighten me with your definition of "agile development". However, I suspect you're defining it in a way that can't possibly be bad -- adequate design time with prudent use of feedback as work progresses. Of course, a definition like that can't meaningfully be differentiated from any other development methodology.

Re:But... is Perl now historical only?

[chromatic]

You can enlighten me with your definition of "agile development".

Certainly. Development occurs in short, frequent iterations, where the time between releases is fixed, but the contents of those releases is not. At the start of each iteration, someone selects the features to work on for that iteration based on their priority. The design of the system as released reflects only the design necessary to support the current feature set. Features are added to or removed from the iteration only if the estimated amount of work possible in the iteration changes.

Long-term planning and overall design is a matter of taste and risk management.

Re:But... is Perl now historical only?

[Anonymous Coward]

It's not a bridge.

Re:But... is Perl now historical only?

[Mutant321]

Perl 5 is still alive and kicking. For just one example of a new project in Perl 5 on a major site, see the BBC iPlayer web interface. (I've heard rumours that another example is youporn ;)

The Perl community is very good at keeping up with the advances of other languages, and in some cases quietly advancing itself. The Moose object system is a good example, which has at least one other language (Javascript) has seen fit to copy.

Moose itself has drawn a lot of inspiration from Perl 6. But Perl 5 has a lot of baggage (as any language of it's age does, e.g. Java), and it'll never be able to do all the things Perl 6 will eventually be capable of.

Perl 6 is a massive undertaking though. They are releasing often, but it's too early to really do much cool stuff with it yet (although you can at least play Hangman). I don't think there's any other language taking on a project so ambitious, at least not one funded by donations, and definitely nothing in the world of dynamic languages.

At any rate, I don't really see how it can be vapourware when they're releasing actual code at least monthly that you can do stuff with.

Re:But... is Perl now historical only?

[SanityInAnarchy]

Most of my work is in spaces where enterprise distributions are much more likely to be present.

So distribute Perl with them.

Google has been learning that lesson the hard way with their Goobuntu project

Citation needed. First few Google results indicate just a rumor, which is probably a hoax.

If the module does use XS, but you can use a version a year or 2 old you can instruct the user how to install the relevant RPMs.

And if you can't?

Any of these solutions requires a stable implementation to rely on.

True. But I wouldn't use "included in RHEL" as a gauge of "stable".

Re:But... is Perl now historical only?

[tabrisnet]

Roommate used to work at google, hence the knowledge of Goobuntu. It's not a hoax, but it is also only an internal project for corp (non-production [production defined as the code that runs Google, GMail, etc]) use only, albeit there was hope for it to replace Prod72, et al.
There are little to no plans to release it for distribution outside the company.

Instruction isn't so hard when you're in the enterprise space, so telling them how to install the relevant RPM is usually acceptable, albeit sometimes you will find that you have ridiculous requirements like a) don't require a compiler b) has to be installable by non-root [cough cough, my current employer]

I'll grant the whole 'RHEL doesn't mean stable' but then again, at least it is a implementation that can be relied upon to not change from month to month, as they will keep the same version throughout most of the series (4.x or 5.x is a series).

Re:But... is Perl now historical only?

[Anonymous Coward]

Ponie is indeed not complete. And never will be.

Almost exactly 3 years ago The Perl Foundation had an opportunity to fund Nicholas Clark to work for 3 months on a project of our choice. One option was to complete the first quarter of Ponie, which would get it to the point where more than one people could work on it in parallel, and work could progress with developers who lacked his deep knowledge of the Perl internals. Another option would be for him to fix a number of core bugs for perl 5.10 development that required a deep and wide knowledge of Perl internals.

Perl 10 uses much less memory than previous versions, runs faster, and has eliminated several long-standing bugs. Ponie, OTOH, is dead. I am very happy with our choice.

Re:But... is Perl now historical only?

[SanityInAnarchy]

sometimes you will find that you have ridiculous requirements like a) don't require a compiler b) has to be installable by non-root

Never ran into trouble as non-root, but it's also been awhile since I've used CPAN.

Why aren't you allowed to require a compiler?

at least it is a implementation that can be relied upon to not change from month to month

Which Ubuntu doesn't. It changes every six months, and that's if you're not using LTS.

Re:But... is Perl now historical only?

[tabrisnet]

Security is one reason one cannot require a compiler (makes it easier to make exploits if you can compile from source & headers).

And yes, Ubuntu doesn't change more often than 6 months, but I don't want to have to chase bugs during the entire 6 month cycle either (or get blind-sided when the next release comes out and my app breaks).

2 year stable cycles are much more friendly to developers & system administrators. 6 months means you do nothing but chase your tail.

Re:But... is Perl now historical only?

[SanityInAnarchy]

Security is one reason one cannot require a compiler (makes it easier to make exploits if you can compile from source & headers).

Meh.

ssh# cat /proc/cpuinfo
ssh# cat /proc/version
ssh# ^D
local$ firefox http://kernel.org/

Headers are easily available. Compile it locally, copy it back. Not much more than a speed bump -- and an irritating one for legitimate users, too.

And yes, Ubuntu doesn't change more often than 6 months, but I don't want to have to chase bugs during the entire 6 month cycle either (or get blind-sided when the next release comes out and my app breaks).

That's what LTS is for -- stable for 3 years.

In practice, it hasn't been a problem for server deployments, though Kubuntu's handling of KDE4 does not inspire confidence.

Re:But... is Perl now historical only?

[SanityInAnarchy]

Whoops, correction: LTS is 3 years on the desktop, 5 years on the server.

It looks as though LTS releases are every 2 years, predictably. Which means that for a server product, you can skip a release, then wait a year after release of the next one before you have to switch.

Re:But... is Perl now historical only?

[tabrisnet]

Whether or not you buy that issue of security, it is a generally accepted practice in some circles. Further, these are often policies handed down from on high. If you argue with them, even come up with good reasons, one often gets back the old "Fiddler on the Roof" answer of "Tradition!" Other answers include "Turnkey solutions" and "reproducibility" and "default configuration of installed distribution".

Re:But... is Perl now historical only?

[SanityInAnarchy]

Nothing like compiling from source to ensure reproducibility. And there's a lot more work that goes into that than just avoiding C modules.

But I see your point, although I still find the policy moronic. And you just made my day with the Fiddler reference!

Re:But... is Perl now historical only?

[jbolden]

First off in rereading my old post I should have said Parrot is much more innovative not python. You didn't quote that part, but it changed the meaning of the sentence.

Rather than quibble, lets start this over. What in your opinion has been the hold up with Perl 6? Where did all the years go as you see things? In your opinion how far off is a release?

Re:But... is Perl now historical only?

[chromatic]

What in your opinion has been the hold up with Perl 6?

Three things. First, revolutionary changes take a while. The original idea of shaving off some of the rough edges of Perl 5 quickly became obvious as too simple and small. Second, the lack of an implementation to give feedback to designers -- Parrot had a lot of missteps and false starts which took a long time to remedy. Third, an almost perpetual lack of funding, meaning that its schedule depends primarily on the availability and interest of volunteers. That's much more difficult to predict, even in software project management terms, than funded developer time.

Where did all the years go as you see things?

If I could go back in time and start over again, I'd get PGE and PCT running on Parrot in the first few months, even in very simple, naively-implemented fashion. Of course, the design team had to invent both of those, so that's a pipe dream anyway. It took around two years of the Perl 6 design process to redesign regular expressions and parsing into Perl 6 grammars, and that was well worth the time.

In your opinion how far off is a release?

I don't believe in giving a date for a stable release of Perl 6.0 in the form of Rakudo, but I will note that Patrick believes that the target number of passing specification tests is around 15,000. As of midnight this morning, Rakudo passed 6,175. That number could certainly be 6,400 by the next release (20 January). It was around 5,000 for the previous release in December. Extrapolate as you like.

Re:But... is Perl now historical only?

[jbolden]

I'm not exactly sure what you were objecting to in my description of what happened with Parrot but I certainly accept yours as conveying the same thing I was trying to convey. I'm not sure what you saw as different.

I have no problem with the 2 years for regexes though that could have happened as an extension to perl 5 (i.e. really slow but at least the syntax would have worked). That is it could have been done in parallel in terms of design.

In terms of your numbers, that's good to see. The 80/20 rule has me worried but it looks like they get to 12,000 or so by September. From there the next 3,000 are going to be the hard ones. What worries me is how hard.

Any indication of how steep the curve is going to be for those latter bugs / features?

As an aside you may want to check the link in your sig. Thanks for the info.

Re:But... is Perl now historical only?

[chromatic]

I have no problem with the 2 years for regexes though that could have happened as an extension to perl 5 (i.e. really slow but at least the syntax would have worked). That is it could have been done in parallel in terms of design.

You're looking for Perl6::Rules, which has several annoying limitations that go away only when you build your own regular expression engine (though to integrate lexical variable handling per the Perl 6 specification, you also have to rework how Perl 5 handles lexicals and aliasing).

Any indication of how steep the curve is going to be for those latter bugs / features?

I can imagine that a few of them will be tricky, but Rakudo right now supports some tricky features, so the balance of easy/difficult to implement won't shift too much.

Re:But... is Perl now historical only?

[jbolden]

Yep. And he wrote that in 2004. I stand corrected, they did do what I was thinking. Why is it at 0.03?

Re:But... is Perl now historical only?

[chromatic]

Why is it at 0.03?

I won't speak for Damian, but my impression is that it's difficult to maintain, in part due to the limitations of Perl 5. Given the appearance of Pugs and PGE, it may not have been worth Damian's time to continue.

Can't get there from here

[djupedal]

$ git clone git://perl5.git.perl.org/perl.git

-bash: git: command not found

Re:Can't get there from here

[Anonymous Coward]

Install git? $ sudo aptitude install git-core

Re:Can't get there from here

[eggnet]

The joke is that git depends on perl.

Re:Can't get there from here

[PReDiToR]

Maybe you forgot to emerge it?

~ $ 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/
Description: GIT - the stupid content tracker, the revision control system heavily used by the Linux kernel team

Will it still be stupid now that Perl uses it I wonder?

Re:Can't get there from here

[ion.simon.c]

# echo "dev-util/git -perl" >> /etc/portage/package.use
# emerge git && emerge perl
# echo "dev-util/git perl" >> /etc/portage/package.use
# emerge git

Right?

And yes. Git will still be stupid. (It's stupid hard for stupid people like me to use the command line client. :/)

Mods on crack

[Anonymous Coward]

There's more insight in a lolcat picture than there is in this comment.

Re:Mods on crack

[jonaskoelker]

I can haz mod pntz?

Re: Perl not historical only

[Dystopian Rebel]

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?

[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.

Re:How about gitting CPAN?

[ArcticFlood]

They're working on Git/CPAN patching functionality. I imagine that other interesting combinations of the two will be seen in the near future.

Summary wording lifted from Ars article?

[Anonymous Coward]

The wording in this summary post looks like it was taken straight from this Ars Technica article.
Ars:

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.

look familiar?

git-gc increases disk usage for Perl

[Anonymous Coward]

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:git-gc increases disk usage for Perl

[Anonymous Coward]

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's for the maintainer, who can also tune the various knobs, and who probably has a beefy machine that can afford to go the extra mile of using lots of CPU time to find an "optimal" pack.

Re:git-gc increases disk usage for Perl

[Anonymous Coward]

the repo on the server is likely packed with high --window and --depth flags, your --aggressive repacks that with 10 and 50 (iirc) respectively which will make it much bigger.

it depends on the size, I think

[Trepidity]

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

[n dot l]

I can't really imagine what I'd do with a distributed version control system

Like I kept repeating in my other post, 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:it depends on the size, I think

[oscartheduck]

I use git, never have used anything else. It was just being developed when I started thinking about using CVS, but I liked the name, so I started with git.

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

[Anonymous Coward]

Merges were simply broken in many SCM's before git came along.

Here's the problem. You start out with with the code in state A, and then develop and then commit to get state B, and then more to get state C: i.e. in graph form A->B->C

Now let's say that when the code was in state B, you decided to branch and work on something else, leaving the code in another state D. This means the ancestry diagram would look like:

1A->B->C
1...\->D
(Sorry - need to use a fixed sized font)

Now, say that you want to the features represented by states C and D, and form a new state, E.

1A->B->C->E
1...\->D--^

The earlier SCM's worked fine up until this stage. What they get wrong is the next step. Say you develop on more on each of D and E to form the diagram:

1A->B->C->E->F
1...\->D--^->G

Where G's ancestor is D, and F's is E. Now, lets merge again. What we want to do is combine the changes introduced by G into F to make a new state H.

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".

All of this is completely obvious in hind sight. The reason why the bad-merge situation carried on for so long is that people though that complex project history was "bad". Now it is realized that project history complexity naturally comes from collaboration, and is perfectly normal for large projects.

Re:it depends on the size, I think

[n dot l]

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 //whatever the git command to forcefully set master to point at mystuff is, I'm barely awake here...

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:it depends on the size, I think

[imbaczek]

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:it depends on the size, I think

[imbaczek]

like when you don't have to manually list commits you want to merge back into a branch, and that if you merge, it doesn't look like one big diff in the history.

Re:it depends on the size, I think

[ToasterMonkey]

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

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

[n dot l]

With subversion, don't you merge a specific range of revisions, such as "C->G" in your example?

Yes, but that gets screwed up all the time. I used to have a system of sticky-notes for tracking what I had/hadn't merged up to a given point and late at night during crunch when you just want the damn thing to work so you can go home you make an off-by-one error, and an i++ gets merged in twice in some ridiculously obscure code that you didn't even write, and you sit there an extra two hours tracking down your error. There are fancy little shell scripts that purport to do the same thing, but they get confused any time the commit graph gets...interesting. And in my experience a team of two people and a single common code file is enough to qualify as interesting with SVN.

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.

SVN 1.5 may have fixed this. I have heard that it's slow (as in "go get some coffee" slow), and I've heard claims that it breaks with complex histories (multiple branches merging in/out of trunk many times over the same period of time), but I've got nothing but word of mouth to back that up.

That aside, and as I've said a few times, the main thing that gives Git its merge power, I find, is its ability to rewrite history. You can literally reorder commits at will, and in many cases I have found that changing the order things are merged in makes a world of difference to how clean the result is, and how easy any conflicts that pop up along the way are going to be to clean up. As an example, we use Git's rebase operation as part of our workflow, which does this:

master: A -> B

git branch hackity
git checkout hackity

do some work

git commit

hackity: A -> B -> C

git checkout master
git pull master //pulls in change set D from the remote source's master branch and updates master to point to it

master: A -> B -> D

git checkout hackity
git rebase master

hackity: A -> B -> D -> C'

Where C' is identical to C (it differs only in its parent commit and in any conflicts you may have had to resolve). You can then merge that into master without creating any new commits beyond C'. All it does is move the 'master' pointer down the graph to point to C' as its head commit, which is the definition of a fast-forward (it can do this since C' includes all of master in its ancestors). This gets really useful when you have C -> E -> F -> ... -> X to rebase as it will let you resolve conflicts as they come up one commit at a time instead of making you deal with everything in one enormous messy diff (though that option is available to you as well, if you wish) and that makes for a much quicker and easier job when you have to figure out what's going on, at least in my experience. And in the end you get C', E', F', etc, with their useful commit messages, instead of the monolithic H:"Merged hackity".

You can also do completely arbitrary stuff. It's very powerful. But I'm just repeating myself here. It really is one of those things you just have to try, I think - I know I didn't really grasp the power of it until I'd been using it for nearly a month, and I'm sure there's still lots of useful capabilities in there for me to discover.

Re:it depends on the size, I think

[ToasterMonkey]

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
http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchmerge.cherrypicking

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

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:it depends on the size, I think

[n dot l]

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.
[...]
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?

The second bit I bolded answers the question you raised in the first. You would clean up your commit history precisely because the contents are more important than the method. That meaningless history is only going to get in people's way if they have to go through the history, so why not replace it with something nice before sending your changes into the shared repository?

While you develop you want to use branches and commits however you see fit, making throw-away instances of each when you experiment with things, reverting old changes, etc (and if you don't see why that's a big deal, you're missing out). But when you submit you don't want people to see a bunch of "work in progress" commits, you want them to see something that reflects a logical breakdown of what you did so that each component can be considered/used on its own. Most of the history rewriting commands are for this. Rebase is a special case of cherry-picking that grabs your work and reapplies it to the current development head (usually, it can be whatever branch you like) so you get a nice clean patch relative to the current code, rather than to revision whatever-it-was-when-I-branched.

Say I write a complex patch that changes a bunch of existing code and then adds a bunch of new stuff on top of that. If the person who wrote the original code that I changed wants to review my work, it would be nice if he could just look up Changeset X: Refactored system X to add hooks for Y rather than digging through 25 tiny commits, mostly labeled "work, work" (or WIP or "undid crap" or whatever) which correspond more closely to my coffee breaks or the times I had to switch to something else for a second than it does to the code - or worse yet one giant commit that includes my changes to his stuff and a ton of stuff he doesn't care about since it's separate.

Cleaning up the history allows me to collapse many dozens of little WIP commits into "Refactoring system X", "Added module Y", and "Optimized module Z to use new hooks exposed in X". Once I do that the maintainers of X and Z immediately know what they need to look at to find the changes that impact them, without having to dig through Y's changeset for any buried changes of interest. That also makes it much easier to cherry-pick individual components of my work into other branches, or perhaps nuke module Y while keeping the new X and Z code. Rewriting history is a powerful ope

Re:it depends on the size, I think

[toad3k]

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 visualization), colored diffs, a history aware grep, bisect (for narrowing down a patch that broke a feature), and dozens of others.

To directly address your comment, changing history may sound like a convenience, but it makes things a lot easier. Some person's patch breaks the website? You may find that the entire change is self contained in one or a small series of contiguous patches, making it super simple to revert. In subversion I've had to track down and revert 15 separate disparate commits over a series of weeks to bring a piece of software back into line. Another benefit is that as you are working, you can add your current work without committing and diff that version against any new changes you make. This makes it extremely easy to develop because you can keep track of just what you've done in say the last 15 minutes, as opposed to the entire day. It is great to be able to go back and review what you've done and tidy it up a bit.

Everything on the client side that svn does, git does better. I want to list more actual use cases, but this post keeps getting too long. So Instead I'm going to encourage you to experiment with git svn at work, or on one of your personal projects. You'll mess up a couple times at first, but the productivity you gain after a few days will be well worth it. I've converted a couple people at work, and they seem happy. Personally my productivity has doubled or even tripled, although I cannot guarantee that will be the case for everyone.

Re:it depends on the size, I think

[BuGless]

There are several reasons why, even in smaller groups, using git is advantageous (even if you have only yourself, no other contributors). I'm not going to name them all, but in my experience (I've used RCS, CVS, SVN and now git), some of the more compelling advantages are that you can:

- Actually permanently erase/fix bad commits from the repository without a painful full dump/tricky edit/restore cycle on the repository. I suppose everyone has some of those occasional moments sometime: "Aaargh, I meant to commit only this one file, not this tar.gz file that happened to be in the wrong place at the right time." Git allows you to correct the mistake without bloat in the repository.
- Patch management (instead of keeping around a bunch of patch files, simply create branches for every patch file you'd normally keep) made easy and trackable.
- And related to patch management: commit early, commit often, then cleanup/merge commits before actually committing them "for real" to the bleeding edge version.

For small groups it means that you simply setup a central git repository everyone pushes to. You get all the benefits of DVCS and classic central management, i.e. it allows you to have your cake and eat it too.

Re:it depends on the size, I think

[WuphonsReach]

SVN 1.5 only came out late last year (sometime in the Fall).

Merge tracking and simplification of merges is still very rough around the edges. It's supposed to get better in 1.6 (no ETA). Better then it was by far in 1.4, but still a work in progress.

For a less technical set of users, I still feel that SVN's central repository model is best. For distributed developers with strong technical skills, there's a lot to be said for git. We're staying with SVN because that works better for us.

Re:it depends on the size, I think

[ToasterMonkey]

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).

Well this is a little different, one uses an entirely different model than the other two doesn't it?

I think it all depends on what features you intend to leverage. I don't remember asking "which is better". I asked if git has real benefits for small teams also, or if SVN (or CVS) are just as good. Git sounds like it's really designed for large teams of strangers on the Internet, I could understand if that doesn't immediately benefit small teams. I'm just asking. At work, we migrated our CVS repository to SVN so we can host it from Apache with Active Directory providing authentication. It was a brain dead simple decision for us. No more shell accounts for everyone and his brother on the VCS server, Apache, flexible authentication methods. None of that had to do with SVN being a better or worse VCS than CVS.
Those are reasons a business might migrate from CVS to SVN, certainly not a small team or even a huge team of kernel hackers for that matter. Well, lack of shell accounts might make SVN hosting services more freely available to the small teams, sort of an indirect benefit.

Everything on the client side that svn does, git does better. I want to list more actual use cases, but this post keeps getting too long. So Instead I'm going to encourage you to experiment with git svn at work, or on one of your personal projects. You'll mess up a couple times at first, but the productivity you gain after a few days will be well worth it. I've converted a couple people at work, and they seem happy. Personally my productivity has doubled or even tripled, although I cannot guarantee that will be the case for everyone.

I'll try to play with it at work I guess.

Another benefit is that as you are working, you can add your current work without committing and diff that version against any new changes you make.

This is the kind of stuff I was asking for. You don't need to carry a repository around on your laptop to track all your offline changes. I think that would benefit small teams, even individual users like me. I suppose I should have said DVCS and CVCS as instead of git and svn. I was interested in any specific advantages of git though. I'm looking at it from a high level you know, connection methods, offline availability, workflows, etc. You talked me into trying it at least, but I suppose I should check out other DVCS systems too.

This story was a surprise to me

[qazwart]

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:This story was a surprise to me

[Eravnrekaree]

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

[Anonymous Coward]

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:This story was a surprise to me

[dkf]

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:This story was a surprise to me

[bcrowell]

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 the slow pace of Perl 6 is really getting tedious. It's starting to be like the "BSD is dying" meme, but even less funny. Nothing about the Perl 6 project makes Perl 5 worse. As pointed out in the /. summary, Perl is 21 years old. In that time, the language, and its standard implementation, have become extremely solid and bug-free, and CPAN has gotten ever more full of goodies that keep me from having to reinvent the wheel. Perl 5 is such a high quality language that it would be stupid to replace it with something that wasn't also of extremely high quality. They could have done a half-assed job on Perl 6 and rushed it out the door, and that would have been stupid, because people would have been faced with a choice of using an obsolete version and a buggy version. Instead, they've decided not to release it until it's done. Other languages with mature designs (C, C++, Fortran, and Haskell come to mind) have similar decade-long cycles before they release a new, incompatible version. That's not a bug, it's a feature. It shows that, e.g., C does what it was designed to do, and does it very well. The fact that a language like Ruby has new versions coming out much more frequently is a bad thing, not a good thing; it shows that Ruby is not a very mature language (e.g., they've been futzing around for years about the best way to handle unicode). If you want your code to break frequently, use a language that has a 1-year release cycle.

Re:This story was a surprise to me

[photonic]

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 is a Dutch guy that worked in Amsterdam at the time, you do the math ...

Re:This story was a surprise to me

[chromatic]

If Perl 6 ever does appear....

I've had working code written in Perl 6 (publicly available, no less) for three and a half years. We've released 24 stable monthly releases of Parrot in a row. The last 13 of those have included stable versions of Rakudo (Perl 6 on Parrot). The question is not "if".

Why bother to learn the differences between Perl 5 and Perl 6 when you can go ahead and learn Python or Ruby?

Perl 6 is a better language than both Python and Ruby. That's not to say that Python or Ruby or bad, but they don't even have lexical variable declarations, let alone multidispatch, hyperoperators, grammars, subtypes, or any of a few dozen other features.

Oh, and did you know that Python 3000 was announced several months before Perl 6? Spread that bitterness around.

Re:This story was a surprise to me

[chromatic]

Perl 5 development does continue and you notice they do make releases very often to make Perl 5 better.

We release a new stable version of Rakudo (Perl 6 on Parrot) every month. If anything, I've argued that Perl 5 should have more frequent releases because of my experiences working on Parrot and Rakudo.

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.

I have. It's not. My rough guess is that at least a developer year of full-time refactoring might start to get the Perl 5 internals in shape to extend it to support at least some of the Perl 6 features -- but that would break almost every piece of XS code in the world.

Re:This story was a surprise to me

[BlueStraggler]

I hate Python. yada yada Python sucks yada yada...

Why bother to learn the differences between Perl 5 and Perl 6 when you can go ahead and learn Python or Ruby?

I think I'll just stick with Perl and not get all bitter and conflicted.

Re:This story was a surprise to me

[Just Some Guy]

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

They renamed it "in".

Re:This story was a surprise to me

[bill_mcgonigle]

Why bother to learn the differences between Perl 5 and Perl 6 when you can go ahead and learn Python or Ruby?

Python is a different type of language. Ruby is more like Perl but until very recently, in dev trees, its performance has sucked. Perl 5 might still be faster.

But you seem to have missed the main point of Perl6 - its VM. When Perl6 is done and there's a Python and a Ruby port to it, you'll be able to mix and match CPAN with RubyGems with whatever the Python thing is and everybody can work together using their favorite languages. And like gcc for c-languages, the Perl6 VM can be where VM hackers go to make VM's better and everybody benefits widely.

Yeah, it would be nice if it were done already. I wonder if they need money.

Re:This story was a surprise to me

[chromatic]

When [Perl 6] is done and there's a Python and a Ruby port to it, you'll be able to mix and match CPAN with RubyGems with whatever the Python thing is and everybody can work together using their favorite languages.

This works today in Parrot. See Parrot Speaks Your Language.

I wonder if they need money.

We need more contributors. Money helps only if it enables people to devote more time to the project. (Money doesn't help me.)

Re:This story was a surprise to me

[bill_mcgonigle]

This works today in Parrot. See Parrot Speaks Your Language.

Cool. It looks as if my information was at least several days old. ;) Though, to be pedantic, the article says foreign library loading isn't quite ready. This sounds like it's going to be super in the very near future (I'm excited!).

We need more contributors.

Thanks for clarifying. I'll chat up my language geek buds.

Re:This story was a surprise to me

[blueberry_tx]

Amen brother. Started on Perl 4 on Sun BSD. Perl made me walk on water. Interest was so strong in the company we used to pay guys like Randal and Tom to come speak. I've bailed my employers out of countless binds with the well-timed perl script. I totally agree with you that Perl 5 was the beginning of the end. It moved perl from the realm of the shell programmer to the domain of the academic. I remember the usenet posts of the time becoming focused on computer science language design goals like closures rather than real world problems. Yes, you can write OO programs in perl, if you remember all the details and you are very consistent in your style. But it requires too much expertise. It became too much of an investment. Now, as you say, the train left the station while perl was deciding on its next destination. No way can I sell Perl to an employer now, despite the fact that it is often the quickest way out of a problem. Python is it, with its error prone indenting, inconsistent syntax, and bewildering (or lack of) type conversions. Been fun venting.

Re:This story was a surprise to me

[john.picard]

Dude I feel your pain but keep a few things in mind:
o Sarge was released.
o Apple did go Intel.
o Pigs can be flown.
If we follow this logic, it is clear that two more things will happen Real Soon Now (tm):
o Duke Nukem Forever will be released.
o Perl 6 will be released.

It's just a matter of time.

Git momentum

[Anonymous Coward]

I don't know the details, but is the following correct?

Linus Torvalds, the creator of Linux, gets dissatisfied with the version control situation and so all by himself he simply sits down and cranks out a new one that has enough advantages to displace the prevailing standards? Is that really right?

Re:Git momentum

[Anonymous Coward]

Yes

Re:Git momentum

[Anonymous Coward]

I don't know the details, but is the following correct?

Linus Torvalds, the creator of Linux, gets dissatisfied with the version control situation and so all by himself he simply sits down and cranks out a new one that has enough advantages to displace the prevailing standards? Is that really right?

Lots of disadvantages. It has momentum from wankers that don't understand that forking is expensive no matter how nice your merge support is, and distributed version control was already available.

Re:Git momentum

[Wonko the Sane]

I don't know the details, but is the following correct?
  Linus Torvalds, the creator of Linux, gets dissatisfied with the version control situation and so all by himself he simply sits down and cranks out a new one that has enough advantages to displace the prevailing standards? Is that really right?

Basically, yes.

Re:Git momentum

[petermgreen]

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:Git momentum

[Karellen]

Where "reverse engineered" should be translated as "telnetted to the bitkeeper server/port and typed 'help'"

Re:Git momentum

[Anonymous Coward]

Lots of disadvantages.

Usually when a statement like that is made it is followed by a list of more than zero examples.

Re:Git momentum

[Anonymous Coward]

According to Andrew Tridgell, the "reverse engineering" consisted in connecting to the BitKeeper server with the telnet client and writing "help". http://lwn.net/Articles/132938/

Gnome project will move to Git soon too

[neonux]

So an even bigger project (at least in term of code size) will switch from SVN to git in the near future.

A survey was run among Gnome contributors and Git won the most support in almost all categories:
http://blogs.gnome.org/newren/2009/01/03/gnome-dvcs-survey-results/

silly

[binaryseraph]

And what silly git came up with this idea in the first place?

Or, shorter answer:

[Jay L]

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 thought svn was that slow, but turns out it's dog-slow. If you remember being floored by the Amiga's blitter graphics: that sort of fast.

Perl...

[dimethylxanthine]

They always had to be different, don't they... (chuckle) ------- "You know everybody is ignorant, only on different subjects."

Confusing...

[Elsan]

Didn't anybody read the summary before it was posted? It should read "The Perl Foundation has announced they have switched their version control systems to git."

Tortoise ?

[dargaud]

So, hmmm, is there a TortoiseGit project for us lazy Windows users ? Which reminds me, is there a GUI for linux equivalent to TortoiseSVN ?

Re:Tortoise ?

[Tanaka]

http://code.google.com/p/tortoisegit/

I volunteer !

[Anonymous Coward]

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:I volunteer !

[persicom]

Oh. Well that explains your looks, now doesn't it. :-)

Re:I volunteer !

[Anonymous Coward]

Whoops, already used up all my mod points :-) Mod parent up: Funny!

Bastard.

[Olix]

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:Bastard.

[JohnFluxx]

You should read the history on why git was created to find out why it's called git.

Migration too soon / git not mature on Win32?

[s1mon]

While the Perl for Linux camp enthusiasts are probably dribbling with uncontrolled glee about now being able to fiddle with git when fiddling with Perl... what about the Perl for Win32 camp? According to Wikipedia about git on Win32: msysgit: "While somewhat slower than the Linux version, it is acceptably fast and is reported to be usable in production, with only minor awkwardness. In particular, some commands are not yet available from the GUIs, and must be invoked from the command line." CYGWIN git: "Regardless, many people find a Cygwin installation too large and invasive for typical Windows use." At least with Perforce it was equally easy to get Perforce up and running on Linux or Win32 boxes. Typically you'd just have to copy one executable "p4" or if you prefer the GUI then additionally "p4v". I can't help feeling that switching to "currently-Win32-neglected" git could possibly harm one of Perl's most attractive qualities; that many modules work cross platform. Surely it would be more prudent for the Perl maintainers to wait until Win32 git is more mature etc?

Re:Migration too soon / git not mature on Win32?

[chromatic]

At least with Perforce it was equally easy to get Perforce up and running on Linux or Win32 boxes. Typically you'd just have to copy one executable "p4" or if you prefer the GUI then additionally "p4v".

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.

I can't help feeling that switching to "currently-Win32-neglected" git could possibly harm one of Perl's most attractive qualities; that many modules work cross platform.

I don't see how. This has very little to do with Perl modules, nothing to do with the CPAN, and everything to do with how people who hack on Perl 5 itself get its source code. (Very few of those use Windows, and they seem confident that Git on Windows is sufficiently usable.)

Re:Migration too soon / git not mature on Win32?

[s1mon]

Hmmm... okay so switching from Perforce to git only changes things for a select few who actually commit? So what's the big deal?

Re:Migration too soon / git not mature on Win32?

[ztransform]

While the Perl for Linux camp enthusiasts are probably dribbling with uncontrolled glee about now being able to fiddle with git when fiddling with Perl... what about the Perl for Win32 camp?

Very good point to consider. The git port to Win32 may not be ready.. (see msysgit).

Re:Migration too soon / git not mature on Win32?

[chromatic]

So what's the big deal?

Good question. I'm not sure why anyone who doesn't hack on Perl 5 itself should care.

Re:Migration too soon / git not mature on Win32?

[slcdb]

Cygwin is the #1 best thing that Windows has going for itself.

So, if git causes a few more people to learn about Cygwin (and the HUGE benefits it provides Windows users), then that is a plus in my book.

Of course

[sam_vilain]

You guys know that, In the UK at least, git is a moderate insult with the same meaning as bastard?

Linus likes to name his projects after himself. Hence, "Linux" and "git" - the British slang meaning of the term being the one implied. I like the Oxford definition; "an arrogant or contemptible person". "bastard" has another meaning, though its slang use approximates the same :-).

Perl not even good for parsing anymore

[Slashdot Parent]

At one point about two years ago, I was parsing a lot of web log files, so I whipped up a perl script to do it. It was taking forever to run, and a coworker suggested that I rewrite the parser in Java. I looked at him like he was from Mars, but I also had nothing better to do while perl was chugging away, so I rewrote the parser.

I rewrote the perl code basically line for line (i.e. no optimizations) in Java using Java's built in regular expression parser, and the thing ran about 100x as fast.

That was the last line of perl I have ever written, and probably ever will write.

Re:Perl not even good for parsing anymore

[chromatic]

I rewrote the perl code basically line for line (i.e. no optimizations) in Java using Java's built in regular expression parser, and the thing ran about 100x as fast.

Random-but-informed guess: these log files are large, and you slurped them all into memory in your Perl program, causing swap and IO thrash. You didn't do that in Java. Non-sequitur conclusion: Perl is useless.

Re:Perl not even good for parsing anymore

[pyrrhonist]

Random-but-informed guess: these log files are large, and you slurped them all into memory in your Perl program, causing swap and IO thrash. You didn't do that in Java. Non-sequitur conclusion: Perl is useless.

He said that he rewrote the program line for line. The way to read an entire file into memory in Perl has no easily translatable analogue in Java, but a Perl program written to read a line at a time in a loop can be translated directly to Java with very little effort. That's why I think that he probably used the later method.

Taking this into account, my guess is that he made the classic mistake of recompiling the regex every time through the loop in the Perl program. However, in the Java program he only called Pattern.compile() once.

I have not compared Perl and Java regex matching speed in almost 4 years, but for the application I was writing at the time, the language made very little difference. The dataset was large enough and the regexes varied enough that the differences in speed between the languages ended by being negligible.

Re:Perl not even good for parsing anymore

[chromatic]

The way to read an entire file into memory in Perl has no easily translatable analogue in Java, but a Perl program written to read a line at a time in a loop can be translated directly to Java with very little effort. That's why I think that he probably used the later method.

I see this problem at least once a week: my guess is the OP used a for loop instead of a while loop. That's a wart in Perl 5, and a very common source of this type of error.

Taking this into account, my guess is that he made the classic mistake of recompiling the regex every time through the loop in the Perl program.

I doubt that, for two reasons. First, I can't imagine a log-processing regexp which is so complex that its compilation time can account for this magnitude of difference in performance. Regexp compilation time is meaningless as soon as you do IO. Second, I doubt that the regexp contained an interpolated variable, so it's likely compiled once and this is not even an issue.

Of course, we're debating code neither of us has read, so it's a silly benchmark anyway.

Re:Perl not even good for parsing anymore

[Slashdot Parent]

Random-but-informed guess: these log files are large, and you slurped them all into memory in your Perl program, causing swap and IO thrash.

If I did that, it was not intentional. But even if I had done that, the machine I was running on had gigs of memory, and the log files were in the hundreds of megs in length.

This was about 2 years ago now, but knowing the way I used to code perl, the perl version would have done an 'open(IN,"<filename") || die' and then a 'while (<IN>) {}'. If perl takes that to mean "read the entire file into memory", then what would have been the more correct perl idiom?

I wouldn't say that perl is useless. I just found Java to have made perl obsolete.

Re:Perl not even good for parsing anymore

[pyrrhonist]

I doubt that, for two reasons.

There's a third reason to doubt it now that I actually think about it. He probably wouldn't be changing the pattern every time through the loop even with a variable. Since Perl 5.6 and higher only compile the pattern once if it doesn't change, this invalidates whatever point I was trying to make in the first place. :'(

Of course, we're debating code neither of us has read, so it's a silly benchmark anyway.

Considering the GP was probably trolling, this whole conversation was probably doomed to the depths of absurdity.

Thanks you, sir, for taking part in this, a case study in pointlessness!

Well done Sam

[phobonetik]

Well done Sam -- you've been working on this for quite some time. In addition, big props for Catalyst IT, Wellington, and open source!

Btrfs and copy-on-write cp.

[spaceturtle]

Two copies of every file are managed by a SVN checkout - the base file and the working file. If the filesystem could store these together then the cost would be halved I understand that btrfs will support a copy-on-write version of cp, which should allow this.

Tried Pike? (Re:This story was a surprise to me)

[BuGless]

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.

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?

I never liked Perl or Python, but graduated from sh to awk to Pike. It's not for everyone, but for people used to C syntax, it's a script language from heaven.

How does git compare to Clearcase?

[raw-sewage]

Honest question: how does git compare to Clearcase? I ask because we used Clearcase at my previous job. I have fairly vivid memories of cursing it at the time. I started using svn for small projects at home and thought it was the best thing ever. In my current job we use svn as well; it's a small team, and the majority of modules have explicit ownership by a single person.

Anyway, I watched that video of Linus talking about git, and reading many of the posts here, I think it sounds really cool. But if my memory is correct, it seems like Clearcase can do many of the same things. The problem I saw with Clearcase, though, was more of a policy program. There was a tremendous amount of code history from people who had no business using any revision control system in the first place. Then there were histories of different peoples' ideologies on how source should be managed. Finally, while I was there, we had a guy come into our group who, in my opinion, had a really sane approach to Clearcase usage. Basically, the best practices he preached made our Clearcase usage look a lot like the good parts of git that everyone talks about. But still, to have sanity in Clearcase, it required that everyone follow the best practices, i.e. a policy matter. Too many people either didn't understand the rational behind the policy, were too stubborn to do it any way but their own, or simply made too many mistakes trying to keep up with the rules of the best practices.

Also, CC was dreadfully slow---everyone talks about how git is faster than svn, and svn is definitely faster than Clearcase (in my experience anyway).

Another area where we struggled was integrating the offshore development team into our Clearcase environment. I am guessing that git is fairly open by design---how does it fare for distributed groups for proprietary development (i.e. where the code needs to be kept secret)? CC may have improved, but when I was there, the offshore team had to use this Clearcase Web program that had limited functionality that couldn't even do everything we needed to maintain said sane policies mentioned above. I remember the offshore team checking code in, then I would go through and re-work the revision history to make it adhere to our policy. (This is about the time I left for a new job.)

Anyway, I'm not trying to promote Clearcase in anyway---I just wonder how it differs from git. And, even if it is fundamentally different, it looks like CC can somewhat be hammered into acting like git in some (perhaps scary) way.

Final question: the git method (as I understand it) certainly makes a lot of sense. But what about for developers who "don't get it"? It seems like it would be easy in such a de-centralized system to bung things up pretty bad for everyone else. I.e., how is sane usage policy enforced?

Re:How does git compare to Clearcase?

[n dot l]

Never used CC but I'll try to answer what I (think I) can:

The problem I saw with Clearcase, though, was more of a policy program.

Many of the issues you run into with any team are, simply put, people problems that are going to need people-based solutions.

Too many people either didn't understand the rational behind the policy, were too stubborn to do it any way but their own, or simply made too many mistakes trying to keep up with the rules of the best practices.

[...]

Final question: the git method (as I understand it) certainly makes a lot of sense. But what about for developers who "don't get it"? It seems like it would be easy in such a de-centralized system to bung things up pretty bad for everyone else. I.e., how is sane usage policy enforced?

I sort of got into this earlier. At the end of the day, code quality is my job. I enforce policy by hand by forcing people's commits to go through me. If the team grew a bunch, I'd divide the code up and designate a lieutenant to be responsible for part of it. You could try to automate this, but, at the end of the day somebody is going to be responsible if the code is a mess and the product doesn't work, and I think it makes all the sense in the world to have that person watching over things from the beginning, rather than only when things break.

Yeah, there's the issue of who and how strict and all the politics that goes along with that. In our case it was definitely worth it to move to that sort of a system, even though it did take a while for people to get used to it. The entire team feels better about the code now, and we're all spending less time per bug than we were before so it's worth the inconvenience and pain - YMMV, of course.

Also, CC was dreadfully slow---everyone talks about how git is faster than svn, and svn is definitely faster than Clearcase (in my experience anyway).

Git is so fast it's just silly. There's really no other way to put it, it's just ridiculously fast. This isn't going to be an issue for you, unless you misconfigure the central repo server or throw in a bunch of random giant binary blobs with all your source or do something horrible like that.

I am guessing that git is fairly open by design---how does it fare for distributed groups for proprietary development (i.e. where the code needs to be kept secret)?

That's another people problem that Git doesn't attempt to solve. All of a Git repo's data sits inside of a single .git folder at the root of a project (or submodule). If you want to move it, just grab your working folder and off you go. There's no authentication scheme or anything - if you can cp, you can copy the repository. If you're gonna offshore, you'll need to rely on good contracts and the law to keep your code safe. Not that CC or anything else would really keep it safe anyway, I imagine - if they can see the code to edit it, they can copy/paste it into another file somewhere else.

I remember the offshore team checking code in, then I would go through and re-work the revision history to make it adhere to our policy.

Well, either that or they could have been paid to have it meet standards, with contractual obligations for them to pass reviews and all, or you pay someone on your team. The work's gotta get done either way. Unless you ignore it, but then you pay come release time, with an even bigger cost (customer confidence) come patch time after that if lots of bugs got through.

Perforce costs money...

[happy_place]

This is really about money. I've used Perforce and CVS and we actually ended up preferring CVS (despite many feature losses) because of the fact that proprietary licenses were just not worth the feature set, and as the project matured we developed enough scripts to compensate for the lack of features. So over time, a pay-for-Version Control system just doesn't seem worth it. --Ray

Mercurial

[CompMD]

I run Mercurial and Git for different projects. Mercurial is for the majority of projects though. Its like Git, except it is written in python instead of C, it doesn't suck on Windows machines, its faster and more efficient, and its easier to work with. I get the feeling that a lot of people move to Git simply because Linus came up with it, and they completely ignore comparison against a real competitor like Mercurial.