The distributed stuff isn't really asked for, or needed. What you really want is the other stuff: easy branching, clean, and stash, and the ability to transfer changes to another client. Most git users (especially those using Github) use the centralized model anyway.Īsk yourself this: Is it really that important to duplicate the entire history on every single PC? Do you really need to peruse changelist 1 of KDE from an airplane? In most cases, NO. You know what? I don't think many people really use distributed source control. It's maddening because its long enough to be annoying, but not enough time to skim Geekologie. Go ahead and wait a minute after every git command while it scans your entire repo.
If you've looked at Linus's git rant on Google code, take a listen to see how he sidesteps the question of scalability.ĭon't believe me? Fine. The typical git user considers the linux kernel to be a "large project". Google also uses Perforce, and when it started to show its strain, Larry Page personally went to Perforce's headquarters and threatened to direct large amounts of web traffic up their executives' whazzoos until they did something about it. It has been developed since 1995 to handle the strain. P4 can handle this because it runs on a cluster of servers somewhere in the bowels of your company's IT department, administered by an army of drones tending to its every need. Maybe you check in binaries of all your build tools, or maybe for some reason you need to check in the object files of the nightly builds, or something silly like that. Because your company's source tree is probably that large. When I say large, I mean about 6 gigs or so. Okay this is subjective because it depends on your definition of large. I was able to hack up git-p4 to do things a file at a time in about an hour. If your repo is more than a couple of gigs, you'll be out of memory faster than you can skim reddit.īut that problem's fixable. It's just a big python script, and it works by downloading the entire p4 repository into a python object, then writing it into git. But you would be wrong, for a number of reasons. "AHA!" you might say, "I can import from my company's p4 server into git and work from that, and then submit the changes back when I am done," you might say. Now, if you have been using git for a few days you might discover this tool called "git-p4". If you screw up, the entire company will know and forever deride you as the idiot who deleted "//depot/main". You have to create a "branch spec" file using a special syntax. It should only be done by professionals: experts in the art who really know what they are doing. And you wrote the code, so you get to merge it back in, because you are the expert.īranching on Perforce is kind of like performing open heart surgery. Want to automatically detect out of bounds array accesses and add missing semicolons to all your code? "git umm-nice-try"īranching on git is like opening a new tab in a browser.
#Perforce download files code#
Share some code with a cube-mate without checking in? "git push". Want to store your changes temporarily to work on something else? "git stash".
Want to restore your source tree to a pristine state? "git clean -fd". So many really obvious things are missing in p4. You might have checked out firefox - but have you checked out firefox ooon GIT? Once you've experienced git, there is no going back, man. Suddenly you have to clone something with git, and BAM! The world is changed. Wow, that's blows the mind! Perforce is great, why would you ever need anything else? And its way better than CVS. If you change your client spec, it synchronizes only the files it needs to. Perforce is pretty fast - I mean, it has this "nocompress" option that you can tweak and turn on and off depending on where you are, and it generally lets you get your work done. So you're happily tapping away using perforce for years and years. Okay, say you work at a company that uses Perforce (on Windows).
0 kommentar(er)
