Slashdot Mirror
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."
but this is fantastic. I use perl every day and love it.
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!
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
$ git clone git://perl5.git.perl.org/perl.git
-bash: git: command not found
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?
Don't thank God, thank a doctor!
There's more insight in a lolcat picture than there is in this comment.
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.
Don't thank God, thank a doctor!
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.
Rich And Stupid is not so bad as Working For Rich And Stupid.
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:
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.
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?
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
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).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
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...
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.
that, and exploding checkouts for all users if your repository also contains binary data like media (images, music, videos).
Rich
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.
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.
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.
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
s/is already done/is already done with the shared part/g
We use it at work and it works much better than SVN did.
Apart from everybody's local copies, we keep a repository sitting on a central server. That repo's "master" branch is our release code and, since I'm responsible for the final product, I'm responsible for this branch. Our workflow is fairly simple:
Note that pushing to master doesn't break anybody else, ever, until they decide they're ready to deal with integrating their patch. Nobody ever does the, "Are you gonna commit first or should I?" thing anymore. Developers that are collaborating on a patch sync via a branch on the central server, or directly to each other's machines, or via emailed patches, whatever they want to do. Git doesn't care and neither do I.
It sounds like a lot of tedious work, but Git is just stupid-fast. In the common case the whole update master, rebase, cleanup commits, push cycle takes about as long as SVN used to take to update and then scan for changes and actually commit anything. In the uncommon case where there's a non-trivial merge, the merges tend to come out a lot cleaner since Git is trying to make your changes to the new master one commit at a time, rather than dumping all of the changes in master on top of your stuff (though it can also do that, if you happen to enjoy pain).
And while I prefer the manual approval approach (which scales by appointing trusted lieutenants to take over some of the work) since it keeps me in the loop and keeps everyone else honest, there's no reason you couldn't automate it. Some projects give everyone push access, but disallow anything but fast-forward (trivial nothing-to-merge) pushes to the central server, others I've heard of have people push to a staging branch and a bot on the server grabs the code, runs the test suite, and merges it if it's good. Access is ssh-based, and there are hooks all over the place, you can set up all sorts of schemes when it comes to control of the canonical central repo.
The thing we've found is that because we've all
When I was considering migrating from SVN to Git I checked out Hg as well since people were making a big deal bout it having a sane Windows UI and all that jazz (and we do a bunch of work on Windows at work). I admit I didn't do a very deep comparison, so maybe I'm selling Hg waaay short here, but Git impressed me and Hg didn't - Hg fans, correct me if I'm being ignorant. The things that stood out in my mind are:
In Hg's favor, Git has no (useful) GUI, but it didn't take long to learn the five or six commands I actually use regularly, and Git's documentation is very good so that was kind of a moot point.
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.
Don't thank God, thank a doctor!
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.
-- 'The' Lord and Master Bitman On High, Master Of All
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.
Don't thank God, thank a doctor!
http://code.google.com/p/tortoisegit/
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.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
My primary reasons for strong preference for git over hg are the following:
Hg is oriented in such a way that the "easiest" workflow is to have multiple branches in multiple different branches. In git, I have exactly one working copy that has all of my history. If I'm making a minor nit change, or a huge sweeping change it all happens in a single directory. Hg generally wants a separate directory/working copy for each branch or line of development.
Hg has a really nice and malleable history via the MQ extension that has quilt like qualities. Which is really, really nice. The problem with it is that once I publish it for someone else to review it, it's not malleable any more (or not as malleable). Maybe that's gotten better, but since I last looked at it, it sucked in comparison to using git-rebase, or one of the Stgit or whatever it was that added quilt like commands to git. Using git, I can publish a branch, get review and commentary, quickly fix the malleable history and re-publish it. Once it passes all review and testing, once integrated into the "mainline", all of the history will be extremely high quality. There will be far fewer commits that are fixed 2 commits later when somebody reviews the code.
git-svn is absolutely wonderful for interacting with SVN repository. My company can use SVN, and I can use git on my machine and work, and re-work a series of small quality commits and then push them to SVN in a automated way. I'm not sure I'd reorganize an SVN repository via it. (Not sure this yet works on Windows).
In Mercurial, heads are deduced by a commit which has no children. So any commit lying around is something that has to be dealt with. In git, I can have a commit that has no children and delete that branch, and it disappears. I can reset a branch to be at any point I like, and it'll be there no matter what else I do.
In the end, Mercurial makes it harder for you to do something "bad" like re-write history too far back in time. At points that is very limiting. Git on the other hand hands you all the chainsaws, if you cut off your legs, they figure that's your problem. In the end, git lets me do what I need to.
I'm a bit of a VCS junkie, so complex interfaces didn't bother me. Once I understand the model of a VC system, I can quickly adapt to it.
- 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?
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.
Where "reverse engineered" should be translated as "telnetted to the bitkeeper server/port and typed 'help'"
Why doesn't the gene pool have a life guard?
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.
-- 'The' Lord and Master Bitman On High, Master Of All
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.
-- 'The' Lord and Master Bitman On High, Master Of All
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.
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 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.)
how to invest, a novice's guide
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.