4 ms·

It is interesting that they mention Perforce releasing a git-compatible frontend/adaptor. I've heard that at least two top-10 code shops (hint: both are in Sea

by ojiikun 14y ago

It is interesting that they mention Perforce releasing a git-compatible frontend/adaptor. I've heard that at least two top-10 code shops (hint: both are in Seattle) built something like this in-house over a year ago since they were unable to switch away from P4 but wanted to placate newer devs that liked git.

draegtun 14y ago
The Perl source code use to be on Perforce before moving to Git a few years back. They probably could have done with this adaptor because it took some effort to get 21 years of Perl commit history over to Git! - http://www.perlfoundation.org/perl_5_development_now_on_git http://www.perlfoundation.org/perl_5_development_now_on_git extra ref: Perl5 git repo: http://perl5.git.perl.org/perl.git http://perl5.git.perl.org/perl.git | Github mirror: https://github.com/mirrors/perl https://github.com/mirrors/perl
i386 14y ago
Many companies I spoke to are stuck with Perforce because its the only version control system that has been proven to scale with thousands of users. Thats not to say Git can't scale but convincing enterprises that Git can scale and showing how they can do it is the next challenge for Git evangelists.
- retube 14y ago
  Many enterprises will stick to expensive paid solutions because if anything goes wrong they need to be able to sue someone.
  - narcissus 14y ago
    And yet most of these expensive paid solutions have EULAs that strictly tell you that you're not going to get anything if you sue them anyway...
  - prawks 14y ago
    they need to be able to dial support. FTFY. Vendor apps and commercialized software aren't purchased (to my knowledge) with the intent of being able to point the finger with the buyer's lawyer. The reason large enterprises prefer Perforce/TFS/etc. is (along with their proven capability to scale) that if something goes wrong they can call the vendor for help. While you might be able to post on a usergroup and hope for a response, you can't call Linus directly. That's a big difference for the people making the decisions from a financial, architectural, and tools-planning level.
    - phaemon 14y ago
      You can buy Git support from several different vendors. Were you honestly not aware of this? Try googling for "Git support".
      - elemeno 14y ago
        Which isn't quite the same as being able to get support from the company which built the software and who can push out a new release to fix the bug that you've just run into.
        phaemon 14y ago
        (is there a better way to do quotes on HN?) > Which isn't quite the same as being able to get support from the company which built the software I'm sure they'll build Git for you if you ask :) Do you think the original authors of Perforce etc. are still with the company? Are you under the impression that their current development team understand the Perforce source code far better than people providing professional Git support understand Git's? > and who can push out a new release to fix the bug that you've just run into. That's exactly what Git support can do. Why not? [edit: to clarify who "they" are]
        hanksf 14y ago
        Christopher Seiwald is still at Perforce. I would have to say: Yes, the current Perforce development team understands the Perforce source code intimately at least as well as the core developers of Git know Git, if not better. Disclaimer: I work for Perforce
- to3m 14y ago
  I don't think git can scale, at least not currently, to the extent perforce can. There's two main problems holding it back: - Storage of database on local drive - the last time I worked with perforce, HEAD alone was 280GB... where would this fit? (there's a presentation about google's use of perforce where they say the metadata alone for their database is >1TB! - so even storing just metadata might not fly) - As number of people using database increases, chance of needing to store hand-modified binary files (Office, Photoshop, Maya/Max/XSI/etc.) increases, and advantage to storing non-modified binary files (old builds, tools, etc.) increases. (Storing things in shares on people's PCs, or having two systems, or whatever, just ain't great.) Centralized locking is pretty much essential for such files, but, being centralized, it's hard to support with a distributed system... The former problem could almost certainly be solved. The latter I'm less sure about. Partly for technical reasons, but partly because the idea that binary files shouldn't be version-controlled is, for some people (and I don't know if the git people are of this mind), a point of inviolable principle.
  - lucisferre 14y ago
    You would be surprised. Git's differential compression is pretty impressive. I worked at an SVN show where HEAD was about 270mb but when I cloned it in Git the bare repo was only 130mb. Git also let's you clone parts of the tree and sections of the history (at least when working with SVN it did).
    - plorkyeran 14y ago
      That's mostly a SVN problem; checkouts are exceptionally large due to that they have a lot of metadata and a second copy of each file for local diffing/etc. which are uncompressed. Perforce doesn't do the same thing.
    - to3m 14y ago
      You may be right. My suspicion would be that a lot of the data is not terribly compressible, and that you'd be looking at over 1TB for the repository of a decent-size project. Add one checkout of head on top; add build products to that. Build products mount up surprisingly quickly, with multiple gigabytes of objects and PDBs being common. 1+TB (and git doesn't support partial checkouts) would make it difficult for people to work off a laptop, or use a SSD. Everybody would need 2 2TB drives on the off chance that they might have to work on more than one project at once. Or you'd have to check less stuff into the git repository. I know people say disk space is cheap; I just don't think it's quite cheap enough yet to piss away to this degree. It's one thing to have a server with masses of storage, I'm just not convinced you can require every client PC to have the same. I could be wrong.
- eob 14y ago
  Can the extensive code-review systems often layered on top of Perforce be achieved with git? As someone who has used both, the workflow features geared towards large organizations and professional-grade code processes have always struck me as a major feature of p4.
  - mullr 14y ago
    http://code.google.com/p/gerrit/ http://code.google.com/p/gerrit/
  - i386 14y ago
    Atlassian Stash was released recently with a code review process built around pull requests (For those that don't know, Stash is a Enterprise Git repository server) http://blogs.atlassian.com/2012/10/stash-13-enterprise-git-pull-request/ http://blogs.atlassian.com/2012/10/stash-13-enterprise-git-p... Disclaimer: I work for Atlassian
- icefox 14y ago
  Having helped several large companies migrate I would agree that this is a top concern, but it can be shown that Git can handle all of the users without any problem. Common tips like: If you are using pure ssh beyond 500 users you want to move away from the stock sshd. When possible setting up git to handle fetches over smart-http can scale git significantly (I would use all available bandwidth to the box before the cpu was anywhere near to pegged). The usual server side backups, routing and distributing load to local offices are all issues that are not too difficult to deal with. Even going through a worse case situation and on purpose corrupting the git database as an exercise is worth doing with new admin's. Inside the enterprise firewall there are a number of tools such as gitolite, github enterprise, gerrit, etc out there that are available to make the users and server admin's happy. Beyond that there are presentations, books, youtube videos, wiki's etc. I found making sure there is one "local export" really helps make things go smoother and and internal chat room / mailing list for Git can't hurt too. Slowly migrating users by teachings the early adopters with git-p4 also helps to prevent the sudden switch on "Monday" that goes horribly wrong causing everyone to loose a few days. The real problem has been shops that have 400GB perforce servers and they employed absolutely no rules about where things would live on the server. This would result in Perforce clients that would cherry pick directories from all sorts of random sub directories across the Perforce server to build a product (v.s. say something simpler like projectFoo/, 3rdparty/, and binaryTools/) The worst are the exceptions in the perforce client such as the perforce client would grab the src/ directory, but exclude src/vs/ because a few years ago someone checked in a visual studio install into the src directory and somewhere someone is still using it so they can't remove/move it... Even if they stick with Perforce companies like this really should clean up their repositories, call it simple professionalism. After a repository is cleaned up (even a basic pass can make a huge deal) then using git on top of perforce or even thinking of migrating is much easier to do. Using Git inside large companies is completely doable right now. In the past when Git was younger I gave a few presentations in the Boston area (where I live) to companies that were interested in learning more. If your in the area and if you just want to pick my brain on the topic or how it might apply to your situation I am always up for grabbing lunch.
  - to3m 14y ago
    What do you do about storing binary files in git? And is git not actually bothered by having a 400GB repository? I was under the impression that sort of thing was just not its intended use.
Jach 14y ago
git-p4 isn't really a good tool if your Perforce repo has branches... But you can get it to do the job with enough effort, and it's probably fine as a simple front-end (I never used it as such). My experience with it consisted of migrating LucidDB from its hosted Perforce server over to GitHub last year, which involved the fun process of learning how to graft new parent-child topologies into a git repo.

by ojiikun 14y ago

draegtun 14y ago

The Perl source code use to be on Perforce before moving to Git a few years back. They probably could have done with this adaptor because it took some effort to get 21 years of Perl commit history over to Git! - http://www.perlfoundation.org/perl_5_development_now_on_git http://www.perlfoundation.org/perl_5_development_now_on_git extra ref: Perl5 git repo: http://perl5.git.perl.org/perl.git http://perl5.git.perl.org/perl.git | Github mirror: https://github.com/mirrors/perl https://github.com/mirrors/perl

i386 14y ago

Many companies I spoke to are stuck with Perforce because its the only version control system that has been proven to scale with thousands of users. Thats not to say Git can't scale but convincing enterprises that Git can scale and showing how they can do it is the next challenge for Git evangelists.

retube 14y ago
Many enterprises will stick to expensive paid solutions because if anything goes wrong they need to be able to sue someone.
- narcissus 14y ago
  And yet most of these expensive paid solutions have EULAs that strictly tell you that you're not going to get anything if you sue them anyway...
- prawks 14y ago
  they need to be able to dial support. FTFY. Vendor apps and commercialized software aren't purchased (to my knowledge) with the intent of being able to point the finger with the buyer's lawyer. The reason large enterprises prefer Perforce/TFS/etc. is (along with their proven capability to scale) that if something goes wrong they can call the vendor for help. While you might be able to post on a usergroup and hope for a response, you can't call Linus directly. That's a big difference for the people making the decisions from a financial, architectural, and tools-planning level.
  - phaemon 14y ago
    You can buy Git support from several different vendors. Were you honestly not aware of this? Try googling for "Git support".
    - elemeno 14y ago
      Which isn't quite the same as being able to get support from the company which built the software and who can push out a new release to fix the bug that you've just run into.
      - phaemon 14y ago
        (is there a better way to do quotes on HN?) > Which isn't quite the same as being able to get support from the company which built the software I'm sure they'll build Git for you if you ask :) Do you think the original authors of Perforce etc. are still with the company? Are you under the impression that their current development team understand the Perforce source code far better than people providing professional Git support understand Git's? > and who can push out a new release to fix the bug that you've just run into. That's exactly what Git support can do. Why not? [edit: to clarify who "they" are]
        hanksf 14y ago
        Christopher Seiwald is still at Perforce. I would have to say: Yes, the current Perforce development team understands the Perforce source code intimately at least as well as the core developers of Git know Git, if not better. Disclaimer: I work for Perforce
to3m 14y ago
I don't think git can scale, at least not currently, to the extent perforce can. There's two main problems holding it back: - Storage of database on local drive - the last time I worked with perforce, HEAD alone was 280GB... where would this fit? (there's a presentation about google's use of perforce where they say the metadata alone for their database is >1TB! - so even storing just metadata might not fly) - As number of people using database increases, chance of needing to store hand-modified binary files (Office, Photoshop, Maya/Max/XSI/etc.) increases, and advantage to storing non-modified binary files (old builds, tools, etc.) increases. (Storing things in shares on people's PCs, or having two systems, or whatever, just ain't great.) Centralized locking is pretty much essential for such files, but, being centralized, it's hard to support with a distributed system... The former problem could almost certainly be solved. The latter I'm less sure about. Partly for technical reasons, but partly because the idea that binary files shouldn't be version-controlled is, for some people (and I don't know if the git people are of this mind), a point of inviolable principle.
- lucisferre 14y ago
  You would be surprised. Git's differential compression is pretty impressive. I worked at an SVN show where HEAD was about 270mb but when I cloned it in Git the bare repo was only 130mb. Git also let's you clone parts of the tree and sections of the history (at least when working with SVN it did).
  - plorkyeran 14y ago
    That's mostly a SVN problem; checkouts are exceptionally large due to that they have a lot of metadata and a second copy of each file for local diffing/etc. which are uncompressed. Perforce doesn't do the same thing.
  - to3m 14y ago
    You may be right. My suspicion would be that a lot of the data is not terribly compressible, and that you'd be looking at over 1TB for the repository of a decent-size project. Add one checkout of head on top; add build products to that. Build products mount up surprisingly quickly, with multiple gigabytes of objects and PDBs being common. 1+TB (and git doesn't support partial checkouts) would make it difficult for people to work off a laptop, or use a SSD. Everybody would need 2 2TB drives on the off chance that they might have to work on more than one project at once. Or you'd have to check less stuff into the git repository. I know people say disk space is cheap; I just don't think it's quite cheap enough yet to piss away to this degree. It's one thing to have a server with masses of storage, I'm just not convinced you can require every client PC to have the same. I could be wrong.
eob 14y ago
Can the extensive code-review systems often layered on top of Perforce be achieved with git? As someone who has used both, the workflow features geared towards large organizations and professional-grade code processes have always struck me as a major feature of p4.
- mullr 14y ago
  http://code.google.com/p/gerrit/ http://code.google.com/p/gerrit/
- i386 14y ago
  Atlassian Stash was released recently with a code review process built around pull requests (For those that don't know, Stash is a Enterprise Git repository server) http://blogs.atlassian.com/2012/10/stash-13-enterprise-git-pull-request/ http://blogs.atlassian.com/2012/10/stash-13-enterprise-git-p... Disclaimer: I work for Atlassian
icefox 14y ago
Having helped several large companies migrate I would agree that this is a top concern, but it can be shown that Git can handle all of the users without any problem. Common tips like: If you are using pure ssh beyond 500 users you want to move away from the stock sshd. When possible setting up git to handle fetches over smart-http can scale git significantly (I would use all available bandwidth to the box before the cpu was anywhere near to pegged). The usual server side backups, routing and distributing load to local offices are all issues that are not too difficult to deal with. Even going through a worse case situation and on purpose corrupting the git database as an exercise is worth doing with new admin's. Inside the enterprise firewall there are a number of tools such as gitolite, github enterprise, gerrit, etc out there that are available to make the users and server admin's happy. Beyond that there are presentations, books, youtube videos, wiki's etc. I found making sure there is one "local export" really helps make things go smoother and and internal chat room / mailing list for Git can't hurt too. Slowly migrating users by teachings the early adopters with git-p4 also helps to prevent the sudden switch on "Monday" that goes horribly wrong causing everyone to loose a few days. The real problem has been shops that have 400GB perforce servers and they employed absolutely no rules about where things would live on the server. This would result in Perforce clients that would cherry pick directories from all sorts of random sub directories across the Perforce server to build a product (v.s. say something simpler like projectFoo/, 3rdparty/, and binaryTools/) The worst are the exceptions in the perforce client such as the perforce client would grab the src/ directory, but exclude src/vs/ because a few years ago someone checked in a visual studio install into the src directory and somewhere someone is still using it so they can't remove/move it... Even if they stick with Perforce companies like this really should clean up their repositories, call it simple professionalism. After a repository is cleaned up (even a basic pass can make a huge deal) then using git on top of perforce or even thinking of migrating is much easier to do. Using Git inside large companies is completely doable right now. In the past when Git was younger I gave a few presentations in the Boston area (where I live) to companies that were interested in learning more. If your in the area and if you just want to pick my brain on the topic or how it might apply to your situation I am always up for grabbing lunch.
- to3m 14y ago
  What do you do about storing binary files in git? And is git not actually bothered by having a 400GB repository? I was under the impression that sort of thing was just not its intended use.

Jach 14y ago

git-p4 isn't really a good tool if your Perforce repo has branches... But you can get it to do the job with enough effort, and it's probably fine as a simple front-end (I never used it as such). My experience with it consisted of migrating LucidDB from its hosted Perforce server over to GitHub last year, which involved the fun process of learning how to graft new parent-child topologies into a git repo.