Slashdot Log In
Perl Migrates To the Git Version Control System
Posted by
Soulskill
on Sun Jan 04, 2009 11:53 AM
from the git-on-up dept.
from the git-on-up dept.
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."
Related Stories
[+]
Ask Slashdot: Git Adoption Soaring; Are There Good Migration Strategies? 346 comments
Got To Get Me A Git writes "Distributed version control systems (DVCS) seem to be the next big thing for open source software development. Many projects have already adopted a DVCS and many others are in the process of migrating. There are a lot of major advantages to using a DVCS, but the task of migrating from one system to another appears to be a formidable challenge. The Perl Foundation's recent switch to Git took over a year to execute. The GNOME project is planning its own migration strategy right now after discovering that a significant majority of the project's developers favor Git. Perhaps some of the projects that are working on transitions from other mainstream version control systems can pool their resources and collaborate to make some standardized tools and migration best practices documentation. Does such a thing already exist? Are any folks out there in the Slashsphere working on migrating their own project or company to a DVCS? I'd appreciate some feedback from other readers about what works and what doesn't."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
que the unreadability jokes (Score:5, Funny)
Re:que the unreadability jokes (Score:5, Funny)
Dear Perl Monger,
TMTOWTDI in Perl. However, in English spelling:
- Que Publishing is a publisher of computer books
- Q was an arrogant but powerful character in ST:TNG who liked to annoy the crew of the Enterprise because they didn't copulate anywhere near as much as James... T... Kirk.
- queue, noun, a line or series of people or things; verb, to form a line or series.
- cul, noun, French, the buttocks
- cue, noun, a signal or indication; verb, to signal, to indicate, to move to position.
2009: The Year Of The Truly Helpful Slashdot Grammar Nazi
Parent
Re:que the unreadability jokes (Score:5, Funny)
Qué?
Parent
Re:que the unreadability jokes (Score:5, Funny)
Here is the script used to migrate perl to the git version control system:
#! /bin/perl
$T=s/Y9/s/0YT-sx^*%fr86%8 ^% v%^* %^* 8*R%^*f vR%^ print @V^58 *$$%&^*7890JH87gV7 65&ygtyR$KLJi"'"%$44:H{"['J{]09'[u"JOPu9)P{"Y8yghO*HYgT*gtO""i'G{*(#h'oiHIO*UYF&d97c 567F&Olf*(Up[;yh['
"[]i
O}{];{:}{;';}
jpJhi8[9
89ouyfo8tIGUYf65D 54$4$edc%$
Parent
This must be the sign (Score:4, Funny)
And there will be much rejoicing!
Seriously, I can't wait!
Re: (Score:2)
This must be the sign. Any day now The Announcement will come: "Perl Six is Ready!".
And there will be much rejoicing!
Seriously, I can't wait!
Right after majordomo 2.
Re: (Score:3, Funny)
Actually, this is an intermediate step. They now know how to tag perl 6, if/when it does arrive.
Darcs vs. Git (Score:2)
I can understand the advantage of using distributed version control. But given all the Haskell people involved (who came in via Pugs) I'm surprised they went with Git vs. Darcs.
Does anyone know if speed is as large of an issue as it is for Linux kernel or was there another reason?
Re:Darcs vs. Git (Score:5, Insightful)
I would guess it's ubiquity and featureset.
Git is built of a patchwork of C and scripts, meaning it's something Perl6 could be a part of someday, and it's also something that's going to be quite familiar to all Perl developers, not just the Pugs guys.
And, Git seems to be quickly becoming the Subversion of DVCS -- fast, open source, everyone has it, everyone knows it, and the alternatives really don't have much compelling to offer.
Parent
Re: (Score:3, Interesting)
the alternatives really don't have much compelling to offer
This is what I have been wondering about. One of the alternatives, Mercurial, does seem to be a compelling alternative to GIT. Would love to hear from anyone who has used both, especially WRT migrations from CVS and integration with Trac. We've been leaning towards Mercurial as it is mostly written in Python (vs C), implements much the same functionality in 1/3rd as many lines of code (according to http://www.infoq.com/articles/dvcs-guide [infoq.com]), and is used by Mozilla, Sun, etc.
These comparisons matter now, b
Re:Darcs vs. Git (Score:4, Informative)
The main things I like about git are its raw speed, its ubiquity (everyone and their dog has a git tutorial), and how simple its primitives are.
That is: I actually started with bzr, and I found that while there were some things that were much easier (bzr uncommit comes to mind), it's a lot easier to actually understand Git under the hood, in case I need to do some deep surgery on some history, say.
Then, too, there just seem to be more tools available -- gitk, git-cherry-pick, even git-stash, are things I don't remember from bzr or hg, but it's been awhile.
I see the point about Python, and I'm absolutely with you there. The reason it's not an issue is, I can't ever remember having to dig into Git source -- the most I might have to do is write a shell-script frontend to some of the tools already there. It's actually somewhat UNIX-y that way -- when was the last time you had to dig into the source of fileutils?
What's more, there are language bindings -- personally, I've used grit in Ruby. Easier than trying to talk to SVN with its XML output.
The main advantage of bzr, by the way, is its handling of directories -- it actually records renames. Git tries to detect them, but it works at the level of file contents, not directory structure -- so, for example, it'll detect if you move a function from one file to another, but it might have trouble if you rename a directory. For example:
mv a b
mkdir a
And, in another branch:
touch a/c
When they merge, where should c go? Git would probably put it in a, since the file's name is 'a/c'. Bzr would probably put it in b, since a was renamed to b, unless the same rename somehow made it into that other branch.
There is another reason I didn't mention -- I use Ruby. I believe Ruby itself is done on SVN, but it seems that every Ruby project ever has moved from SVN to Git, and most of them to Github. And it's just awesome to work with Github projects.
Parent
Re: (Score:3, Interesting)
My primary reasons for strong preference for git over hg are the following:
Hg is oriented in such a way that the "easiest" workflow is to have multiple branches in multiple different branches. In git, I have exactly one working copy that has all of my history. If I'm making a minor nit change, or a huge sweeping change it all happens in a single directory. Hg generally wants a separate directory/working copy for each branch or li
Re:Darcs vs. Git (Score:5, Interesting)
I can understand the advantage of using distributed version control. But given all the Haskell people involved (who came in via Pugs) I'm surprised they went with Git vs. Darcs.
Does anyone know if speed is as large of an issue as it is for Linux kernel or was there another reason?
Actually, you might not know this, but the Haskell folks already moved over to git from darcs a while ago. They were having scalability issues and did a 6 month survey to determine which distributed version control they should go with and determined that git was the best of the breed. Here are the links:
Parent
But... is Perl now historical only? (Score:3, Insightful)
I mean, really. Git's good -- git's even really good -- but what does it matter if Perl 6.x is gonna take longer than Duke Nukem Forever to come out? It's the clear and obvious winner of the OSS vaporware award. [And, yeah, I'm aware that there are beta releases -- or, at least, pre-releases -- but "where's the beef" already?] I'm not a big fan of ESR, but I have to admit "release early and release often" is something I happen to agree with.
$.02
Re:But... is Perl now historical only? (Score:5, Insightful)
Parent
I volunteer ! (Score:5, Funny)
There are too few developers working on Perl 6, adding a few would actually speed it up. There is a lot of work to be done, and people are spread too thin.
I don't have a clue regarding perl, but looking at some perl scripts, I think I can do it. I mean all you have to do is type #! /bin/perl and roll your face over the keyboard.
Parent
Re: (Score:2)
I mean, really. Git's good -- git's even really good -- but what does it matter if Perl 6.x is gonna take longer than Duke Nukem Forever to come out?
Maybe Git will help it come out sooner. I know I'd much sooner contribute if I could just fork the project on Github, as opposed to sending patches against a Perforce repository.
And be careful with the DNF jokes. We said the same about Vista, and look what happened.
I'm not a big fan of ESR, but I have to admit "release early and release often" is something I happen to agree with.
Then you obviously missed that point. "Release early and often" is about making the code available, and there are beta/prereleases available for Perl6, so they've got that covered.
It absolutely should not apply to final versions. Those should be
Re: Perl not historical only (Score:5, Insightful)
Fixed the subject line for you.
Last year, I completed two important Perl-based projects for my employer. I also use Perl at least once a week to run analyses of my Web server logs. I prototype Web applications in Perl and often just put the prototype into production because it works well. I'm still using Perl that I wrote over 10 years ago, with NO changes, on several OSs. And I use Ubuntu Debian, of which Perl is an integral component.
Perl is great. If I want what it doesn't have, I use a different language. But when I want regular expressions, CPAN, quick and secure CGI, analysis of large data sets and general parsing, easy database integration, and efficient portability from server all the way down to embedded systems, Perl is the first language I consider. Ruby might be ready for the real world one day. And Python is good for other things, but it is not a replacement for Perl.
Parent
Re: (Score:3, Informative)
If you just want Perl6 you can use it today with Pugs. That is the "release often" and it finished.
If you want a real release candidate the problem is Parrot. Perl6 attempted some very complex stuff with the runtime, that so far has been challenging to implement. There is no guarantee these problems will get solved.
Re:But... is Perl now historical only? (Score:4, Informative)
You can use Perl 6 right now if you want. It is available, just not rated for production yet. I can understand that probably not many folks will want to use it for real world purposes, but this is pretty far from at least my definition of vapor.
Parent
Re: (Score:3, Interesting)
"release early and release often" is something I happen to agree with
Really? What about other design projects, like building a bridge? Should they release early and say "tell us if it collapses, and we'll fix the design"?
With all this talk about agile programming -- in which you just keep adjusting things until someone says "good enough for me" -- sometimes people forget that design is important, too. Agile development is certainly a valuable tool for many kinds of development projects. But it is not the an
Can't get there from here (Score:5, Funny)
-bash: git: command not found
Re:Can't get there from here (Score:5, Informative)
The joke is that git depends on perl.
Parent
How about gitting CPAN? (Score:2, Insightful)
I propose using Git for CPAN too.
Can be cool - if you want to make changes to a module that is not yours, you should be able to branch it, make the modification, and offer the branch to the original author.
and it can be better - operate against your personal branch of CPAN.
Re: (Score:3, Interesting)
They're working on Git/CPAN patching functionality [perl.org]. I imagine that other interesting combinations of the two will be seen in the near future.
This story was a surprise to me (Score:5, Interesting)
My first response was "Do they still develop Perl?"
When I first started with Perl 3.0 many, many years ago, I fell in love with the language. It was flexible, powerful, and could do all sorts of amazing things. Version 5.0 brought in objects, but the way they worked was a little kinked. Defining classes in Perl is not easy, and I always have to go back to the manpage to make sure I've got all the incantations. Many times, I simply use object oriented structures and forgo the object definitions.
Perl 6 was suppose to fix everything. It would improve the way class definitions worked. Perl 6 would be a better object oriented language while still allowing you to hack out quick scripts like you would in shell script.
Well, Perl 6 was announced almost a decade ago, and it still isn't released. Meanwhile, Python has become the defacto scripting language for the OSS world. Even I, a Perl fanatic whom makes most Mac fanatics look mellow have to admit that, and learn Python. I hate Python. It's use of indents for flow control is a throwback to Fortran. Its lack of regular expressions in the string object (you have to import a special "re" object) makes it maddening. Why o' why does Python use "pop" for arrays, but not "push"? What were the designers on when they decided "exists" is not a member function of hashes -- excuse me -- dictionaries and arrays? Why this syntactic distortion of over 50 years of computer programming overturned?
But, I am now a good Python developer writing all of my stuff in Python. I am use to the cryptic error messages that don't really explain the problem (after all, Python has only been around for a bit over a decade). I am use to the fact that basic structures of the language change from implementation to implementation. I even like the fact that "numbers" are divided into multiple types although you really can't declare a number to be a specific type. It does allow you to experience the fun of your division suddenly not working because it is INTEGER division. (And, of course, Python 3.0 will change this very basic part of implementation and break everyone's Python script!)
Perl could have been the language of the web. After all, even Perl has fewer syntactic quirks than PHP, but it is PHP that is the glue behind server side webpages. While the Perl gurus were redesigning Perl, PHP got incorporated into an Apache module and added the syntactic sugar needed to run sessions and keep variables between PHP scripts.
So, Perl, the glue that use to keep the Internet flowing has become a niche language. Almost all of the younger developers I know never bother to learn it, and fewer and fewer jobs are interested in it. It is Python that everyone wants. It is PHP that runs the message boards and CMS pages. Perl is simply no longer in the picture.
Every few years, something I've learned becomes obsolete. It's the field. One time, I knew how to setup a UUCP network. One time, I could setup a Gopher site. I also learned all the quirks of HTML 3.2 and had to lose that to learn CSS. I use to know C shell programming, and of course I was a C developer and an expert in the curses library. I've usually gave up these technologies without too many problems.
Perl is different. I've been a Perl developer for over a decade. I've always loved the language, and I've solved many, many issues with it. One place where I worked was a .NET development shop when they suddenly realized that some major component of their software couldn't retrieve the information from the network. It would take weeks to fix! I wrote a Perl script in four hours that took care of the problem.
Another place I worked had damage in a customer's database. They had everyone in the company searching for problems and re-inputing the information by hand into a clean database. A Perl script I wrote in a couple of hours did the job. Perl made me the expert. I was the wunderkind. Perl allowed me to do the impossible. It was quick, hackish, yet could also be used to build powerful programs
Re: (Score:3, Insightful)
I have used perl extensively adn one thing its OO is not is "complex". Bless is very easy to use, its a very simple model? It couldnt be easier.
As far as rewriting your existing scripts for perl 6, i wouldnt do this. Use Perl 6 for new projects, use Perl 5 for old ones.
Perl 5 remains a good quality platform for development so do not let the situation with perl 6 discourage you from using perl 5. Perl 5 is still a great development platform and is better than python and ruby in many ways.
Perl 5 development
Re:I'd rather seen they moved to Subversion (Score:5, Informative)
There are significant advantages of Git over Subversion. RTFS for some.
Just to add insult to injury -- often, a Git checkout, which includes all history, takes up less space than a Subversion checkout for the same project, which doesn't even include recent commit log messages.
But think about this -- you're saying they should use a big, slow, central server, as a single point of failure, crippling offline development, complicating branches (especially merges), and several orders of magnitude slower for just about every operation, just so you don't have to learn a "weird" tool?
Parent
Re:I'd rather seen they moved to Subversion (Score:5, Insightful)
I am intrigued git and adoption by a major project like Perl is a big endorsement, so please don't take this as a rhetorical question: isn't centralization the heart of source code management? As a project lead, I'm reluctant to have repositories sprouting like mushrooms everywhere and everybody having their own little "trunk," and developers arguing who should have to merge with whom before each release. Is this reluctance totally unfounded, or easily solved administratively, or a valid concern with a peer-to-peer SCM model?
Parent
it depends on the size, I think (Score:5, Informative)
These distributed models work best if it's a large team, which potentially has more than one level of hierarchical structure.
You do typically have a canonical central repository managed by the project lead (in the Linux kernel's case, Linus's tree). But then sub-section leads might have their own canonical repository for that sub-section, and merge in their team members' changes into a stable state that they approve of before asking for those changes to get merged into the central branch. Or they might bundle up some particularly important set of changes for early merging "upstream", making sure they cleanly apply against the current central repo. That's all a nightmare to manage in SVN, which conceives of branches as something you do occasionally and keep around for a while, not as a hierarchical project-management tool.
On the other hand, if you have a relatively small or flat team, or one where the sub-sections break down really cleanly so each one can have its own central repo, it might not buy you much. I'm working on a small project with 4 people at the moment, and SVN is perfectly fine, and I can't really imagine what I'd do with a distributed version control system (I'd just use it like a centralized one, pushing everything to the one repo everyone pulls from).
Parent
Re:it depends on the size, I think (Score:4, Informative)
I can't really imagine what I'd do with a distributed version control system
Like I kept repeating in my other post [slashdot.org], you can actually use branches and commits as tools to aid your own work without affecting others or polluting the commit logs with junk "Work in progress" commits. That and you get sane merges. Both of those are huge, even if your team is just you and your imaginary friend.
Parent
Re:it depends on the size, I think (Score:4, Informative)
Imagine doing this (half-asleep, bear with incorrect/silly git commands):
git pull master
git branch mystuff
Two weeks go by, many, many changes have been made in master, and you do a ton of work in mystuff:
git checkout master
git pull master
git checkout mystuff
git merge master
Or alternately:
git checkout master
git pull master
git merge mystuff
Oh, and in both cases, the merge turns into a single commit without so much as a pointer to the history. You can put that in the commit message yourself, if you like, that's your only option.
That's essentially all you can do with SVN. You don't have the ability to rebase or cherry-pick or otherwise fiddle with your commit history so as to get a clean straight-forward merge in SVN, and because of that merges are slow and usually painful. So while you could regularly merge to keep things sync'd and simple, nobody actually does that in practice. It leads to what many SVN based teams call "merge day" where it literally takes a day to merge in a feature branch and work out all of the conflicts.
The other issue is that branches have to be made on the server and then checked out separately, which makes them expensive. First you're polluting the global history, and second you have to do whatever build environment setup you do once you checkout your branch (you can "switch" your branch over which works in place, but that gets flakey as the things you're switching between diverge - maybe this has been fixed). So for any small-to-mid sized task you're (in practice) going to avoid creating a branch. You'll work right in trunk (master in SVN parlance). You won't make commits as you go, as those go straight to the server where they can never be erased, so your only "oops, undo that" feature you have is the undo buffer in your text editor, or picking and choosing lines from a diff, or sheer memory. And of course you *can't* make that one commit until you've pulled down all the changes that happened since your last update (yes, while your changes are sitting uncommitted in your working files), and those changes get dumped into your working copy as changes, indistinguishable from the code you just typed in diffs (except for conflicts, those get marked in the usual manner)...
All of those problems go away when you can easily merge, because then branches cease to be painful - but then I've found that the best merges Git makes are the ones you get from rebaseing or cherry-picking, which SVN cannot do.
Parent
Re: (Score:3, Insightful)
All of those problems go away when you can easily merge, because then branches cease to be painful - but then I've found that the best merges Git makes are the ones you get from rebaseing or cherry-picking, which SVN cannot do.
When was the last time you used SVN? Everything you just said is very confusing, 1.5 came out over a year ago and seems to have most of the features you say it does not.
http://subversion.tigris.org/svn_1.5_releasenotes.html [tigris.org]
http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchmerge.cherrypicking [red-bean.com]
As for rebasing, this is the first I've heard of it. It sounds interesting, but I don't really understand the problem it was meant to solve.
From http://www.kernel.org/pub/software/scm/git/docs/user-manual.html [kernel.org]
Re: (Score:3, Informative)
Trying to explain why git is better than svn is like trying to explain why svn is better than cvs. To someone who has never used it, they simply can't imagine anything better. I've actually been in the position of advocating svn over cvs and been shot down with arguments much the same as you are making now (that cvs has almost everything svn has).
There are a myriad of git commands that do all sorts of useful stuff. mergetool, cherry, rebase -i (interactive), add -i (interactive hunk based add), gitk (for
Re: (Score:3, Insightful)
1A->B->C->E->F->H
1...\->D--^->G--^
Unfortunately, the problem with earlier SCM's is that in creating state H they try to merge both D and G into F. They forget that D was already merged into E, and try to merge it in again. This obviously causes problems; either conflicts; or even worse, mysterious code duplication or deletion.
To work around this, many coders made scripts that recorded the previous merge point through automated tags or other magic. Unfortunately, the diagram I showed above is a relatively simple case. The history graph can be much more complicated, and simple scripts will break.
Git solves all of this by knowing the topology of the ancestry diagram. It knows exactly what has been previously merged, and what hasn't. This means when multiple branches are merging between themselves it "just works".
With subversion, don't you merge a specific range of revisions, such as "C->G" in your example?
Also, while maybe not as nice as git's merging, isn't subversion 1.5's merge-tracking exactly what you're talking about? Now the range of revisions doesn't need to be specified, AFAIK.
source [red-bean.com]
I'd love to hear from anyone who has both git and svn experience. I't be interesting to know if there are any features that would benefit smallish teams, or if subversion has more or less been keeping up in that area.
One m
Re: (Score:3, Informative)
Re: (Score:3, Informative)
isn't centralization the heart of source code management
Not necessarily. Consider a common case:
- Project A works on a significant feature (say a new file system)
- As part of their work, they significantly restructure some related part (say how a fs ties into the kernel) and update other parts of the source to match
- Project B works on a different feature (say overhauling the interrupt thread implementation on SMP systems)
- Project B wants to update the same related parts (say how kernel modules, including file systems, tie into the kernel)
- Project A is alread
Re:I'd rather seen they moved to Subversion (Score:5, Informative)
We use it at work and it works much better than SVN did.
Apart from everybody's local copies, we keep a repository sitting on a central server. That repo's "master" branch is our release code and, since I'm responsible for the final product, I'm responsible for this branch. Our workflow is fairly simple:
Note that pushing to master doesn't break anybody else, ever, until they decide they're ready to deal with integrating their patch. Nobody ever does the, "Are you gonna commit first or should I?" thing anymore. Developers that are collaborating on a patch sync via a branch on the central server, or directly to each other's machines, or via emailed patches, whatever they want to do. Git doesn't care and neither do I.
It sounds like a lot of tedious work, but Git is just stupid-fast. In the common case the whole update master, rebase, cleanup commits, push cycle takes about as long as SVN used to take to update and then scan for changes and actually commit anything. In the uncommon case where there's a non-trivial merge, the merges tend to come out a lot cleaner since Git is trying to make your changes to the new master one commit at a time, rather than dumping all of the changes in master on top of your stuff (though it can also do that, if you happen to enjoy pain).
And while I prefer the manual approval approach (which scales by appointing trusted lieutenants to take over some of the work) since it keeps me in the loop and keeps everyone else honest, there's no reason you couldn't automate it. Some projects give everyone push access, but disallow anything but fast-forward (trivial nothing-to-merge) pushes to the central server, others I've heard of have people push to a staging branch and a bot on the server grabs the code, runs the test suite, and merges it if it's good. Access is ssh-based, and there are hooks all over the place, you can set up all sorts of schemes when it comes to control of the canonical central repo.
The thing we've found is that because we've all
Parent
Re:I'd rather seen they moved to Subversion (Score:4, Insightful)
Other posters have gotten the main ones, but a few points you may have missed:
First, yes, you can use it in a centralized manner. It does that much better than Subversion does. For a taste, use git-svn -- crippled, but in many ways better than vanilla subversion.
To address your actual concerns, though:
I'm reluctant to have repositories sprouting like mushrooms everywhere and everybody having their own little "trunk,"
The fact that everyone has their own "repository" as a working copy doesn't mean there have to be "repositories sprouting like mushrooms". You can do that, and it works well -- see Github -- or you can just have one "canonical" repo that everyone pushes to, or both.
Or you can have other models -- I believe Linux is hierarchical, such that various subsystems each have their own maintainers, with their own subsystem-specific repository. Some large patches, like suspend2 or the Ubuntu patches, certainly maintain their own repositories. But it's actually quite easy to send relevant changes back up the chain -- Linus can pull from whichever of those he wants, and apply them to the official tree.
In fact, that's something much more difficult to do on Subversion -- having only one person with commit access would be stifling. On the other hand, with Git, commit access can be based on trust, not on productivity.
Just as an example: When I want to make a non-trivial change to a project on Github, I just fork it. Then, when I'm satisfied with my changes, I send a pull-request back. There's no question as to which is the "official" version -- on the other hand, if my change really is a good idea, and they refuse to merge, maybe I'll just keep developing on my own, merging in their changes, and before long people are seeing me as the "official" version.
and developers arguing who should have to merge with whom before each release.
But the problem of which version is official, and who needs to merge with whom, is a social, not a technical problem. You have the exact same problems with SVN, if you use it properly -- we tried this for a bit, with everyone working on their own branch. Merging was impossible, even though there was a "real" trunk. (Or, I should say: It was possible, but expect to wait a half hour or more for SVN 1.5 to figure it out -- or expect to spend a half hour or more of your own time giving SVN 1.4 the right revision ranges.)
Then we started using git-svn, everyone working off trunk, and keeping their own private Git branches locally. This way, merging was trivial, because Git is awesome at merging. The downside is, local Git commits get turned into git-svn commits when you send them to SVN, which changes the sha, which makes it that much harder to merge any other local branches you might have -- it was definitely an upgrade to start some new projects on pure Git.
Parent
Re:I'd rather seen they moved to Subversion (Score:5, Informative)
git makes branching and merging easy enough that the question of "where is the central line?" isn't really an issue- developers can easily work on their own branches without worrying about other branches, and you can still push your developer branch to the central repository so that the question of "Where is this change? Is it in Steve's branch? Do I need to connect to his repository?" is also not an issue- Steve's branch can easily be in the central repository, Steve just needs to push changes in, just like he'd normally need to commit changes. Git's primary difference there is that "Steve's repository" is pretty much just a robust staging area for changes.
However, if you're used to centralized version control, you may miss things switching to git:
- Pick whether you want all or nothing in advance. You can either have "shallow" checkouts, which leave you with a crippled, broken, and useless copy that has no access to history functions, or you can have every change ever made. Once you've made this choice, you can only change your mind by cloning again. There is no way to gracefully get history as it is required.
- This means: no partial checkouts. This is a problem if you're used to versioning large binary files, or have large files which you won't care about for anything other than auditing reasons after a certain time.
- Which also implies: no "modules". This is a problem if you have lots of small related projects, which together make up one massive pool of code. You can have one massive project which everyone uses all of, or you can choose not to track the origin of files which you copy from one project to another. Having a "common" project shared by several others is not possible.
- Unless you try the "submodule" support, which is a broken hack that can devour changes far too easily to trust it to end-users. And submodule support does NOT allow copies from one "submodule" to another, or to your main project. Not while retaining history, anyway.
This is really all one flaw, re-stated five times. Fix this and git will be able to replace any centralized system. Without the change, I can't recommend it to anyone who is involved in a centralized project- at least not when there is a reason for being centralized.
Git is, despite proponent's claims, great for small projects which don't actually need to talk to anyone else and don't need to interface with any other projects. If your project involves other "projects" where the line between one and another is the least bit blurry, avoid git.
Parent
Re: (Score:3, Insightful)
Can you elaborate on this?
The specific scenario I use SVN for is where a single repository (not svn:externals, which I agree are broken, though for other reasons) has several related but independently developed projects, and a couple of "common" projects shared by all (mostly library-type functions). Using svn we can check out these individual folders easily, work on them independently, and ignore completely (ie: never check out) folders for projects we aren't involved in. It is possible and easy to copy files from one project to an
Re:I'd rather seen they moved to Subversion (Score:4, Informative)
There are also advantages to Subversion that Linus states himself [1]. Really the only one of note is that Git isn't so great at having multiple projects in the one repository and the recommendation is to have one per repository and have a super-project that contains pointers to others - which isn't so great a solution.
[1] It was stated in relation to the layout of the KDE repository: http://git.or.cz/gitwiki/LinusTalk200705Transcript [git.or.cz]
Parent
Re: (Score:3, Insightful)
that, and exploding checkouts for all users if your repository also contains binary data like media (images, music, videos).
Re:I'd rather seen they moved to Subversion (Score:4, Informative)
takes up less space than a Subversion checkout for the same project
Only if you actually *want* the whole project. If on the other side you just want a single file or subdirectory, say in a large gigabyte size repo with graphics, textures and stuff, you have kind of a problem with git. A git clone always downloads the whole thing, svn on the other side allows you do download just what you want, so the download with SVN can easily become a few orders of magnitude smaller then with git.
git could really use a way to do shallow clones so that only those pieces get downloaded that are actually needed, git-clone --depth is a start, but not quite enough.
Parent
Re: (Score:3, Informative)
You can only split a subdirectory out into its own project if it's not related. If changes ever cross the boundary, you want history. If you just want to point someone to a single place for a checkout, you want the versioning system to have some notion of that.
Meanwhile: Burning a DVD is possibly slower or faster depending on the situation. It's a pretty stupid option either way, though. In this day, any time you're in a situation where using physical media is a better option, you've got a broken protocol.
Mods on crack (Score:3, Insightful)
Re: (Score:2)
Whatever. Tim the Enchanter was a mangy scotch git, and he wasn't weird - was he?
Re:Tortoise ? (Score:5, Informative)
http://code.google.com/p/tortoisegit/
Parent
Re:Git momentum (Score:5, Informative)
Roughly
Linus was very resistant to version control at all and could always find a reason (or excuse) not to use each version control system that came along.
Eventually someone decided to listen to every demand from linus and create a vcs that met all of them. The catch was it was not FOSS and the gratis version had some pretty obnoxious terms. Things reached a head after someone at OSDL reverse engineered the protocol and linus was basically forced to either scrap bitkeeper or quit his job at OSDL.
However the period with bitkeeper had convinced linus that version control was a good idea. But all the alternatives he could find were either too centralised or too slow. So he hacked together git.
Parent
Re: (Score:3, Informative)
Where "reverse engineered" should be translated as "telnetted to the bitkeeper server/port and typed 'help'" [lwn.net]