4 ms·

I don't know why my company use perforce

• ebikelaw 8y ago
  What’s wrong with it? Perforce is excellent. Git is OK but owes a lot of its popularity to its price.
  • pletnes 8y ago
    The fact that branching = copied directories is certainly wrong.
    • ebikelaw 8y ago
      Branches are virtual copies/views in p4.
      • pletnes 8y ago
        Then some user will copy a directory, check it in, and declare that s/he «has branched the code». Oh, and quietly pull in some other directory, which is clearly not branched. This is just broken IMHO.
• JackCh 8y ago
  Probably because Perforce scales to truly massive monolithic repos while git traditionally doesn't (the insanity going on at Microsoft notwithstanding.) Personally I feel the best method is using lots of small repos, one for each service or library, that get stitched together by the build system. I know some large tech companies have created such systems and I have experience with one of them working very well (they migrated from perforce). But this is a big change from the monolithic repository model and institutional inertia is very real. (Perforce will eventually start to hit a wall when you get to the point where money won't buy hardware big enough for Perforce to serve your repo fast, but that's a very long way off for most organizations and I believe there are some mitigations for it.)
  • jogjayr 8y ago
    > Personally I feel the best method is using lots of small repos, one for each service or library, that get stitched together by the build system. But then your teams have to manage dependencies - or your release team has to do it for them. It's very easy to run into diamond-dependency problems or runtime classpath issues.
    • JackCh 8y ago
      Sure, but in practice it seems to work pretty well.