대기업이 Perforce를 사용하는 이유는 무엇입니까? [닫은]

구글, 페이스 북, 퍼 포스 등 일부 대기업에 대해 들었습니다

SVN / Git이 Perforce를 대체 할 수없는 이유가 있습니까?

타당성은 아마도 이전보다 덜 관련이 있지만 Perforce는 Subversion보다 큰 리포지토리에서 더 잘 수행되는 경향이 있습니다. 이것이 Microsoft가 소스 저장소를 구축하기 위해 Perforce에 소스 라이센스를 취득한 이유 중 하나입니다. NT의 저장소는 괴물이며, 상업적이거나 다른 많은 제품이 그것을 처리 할 수있는 것은 아닙니다.

또한 적어도 한 번은 Perforce의 시각적 도구가 Subversion 또는 Git에서 제공하는 것보다 훨씬 우수했습니다. Meld를 ​​사용하는 경우 아마도 이전보다 덜 중요하지만 분기 및 병합 시각화를 포함하여 Perforce가 매우 훌륭하게 수행 한 몇 가지 사항이 있습니다. Perforce에 마지막으로 접촉 한 지 약 3 년이 지나서 Github의 접근 방식보다 더 정교 해 보였습니다.

Perforce를 사용한 후에는 실제로 장점이 무엇인지 이해할 수 있습니다. 그들은 오랫동안 무료 2 사용자 서버 옵션을 제공해 왔으며 경험이있는 소스 코드 관리 시스템에 따라 팀이 잠시 테스트 한 후 업그레이드 비용이들 수 있습니다. 소규모 상점의 경우이를 사용하고 좋아하는 개발자의 네트워크 효과와 함께 Perforce가 유료 사용자를 얻는 이유입니다. Dmitri의 냉소적 인 발언과 달리 소규모 개발 팀이있는 회사에서 Perforce를 판매하기 위해 CTO가 많이 이기고 식사하지는 않았지만 그러한 장소에서 사용됩니다.

내가 Microsoft 외부에서 작업 한 대부분의 프로젝트는 Git, Mercurial 또는 Subversion에서 합리적으로 잘 처리 될 수 있으며, 내가 선택한 대부분의 회사가 이러한 옵션 중 하나를 사용한다고 말합니다. 그러나 일반적으로 저장소 크기, 분기 및 병합 모델, 팀 경험 / 역사의 조합으로 사람들이 상업용 도구를 사용하도록하는 좋은 지점이 있습니다. 예를 들어 큰 Git 리포지토리는 거의 보지 못했습니다. 이것은 Git의 본질적인 제한으로 인한 것이 아닙니다. 나는 그 점을 완전히 무시한다. 그러나 Windows NT와 같은 일부 프로젝트에서는 무료 솔루션에 대한 실질적인 제한이있을 수 있습니다.

svn, git 및 Perforce는 사용자로서 서버를 설정하고 유지 관리하는 데 능숙합니다.

회사 나 저와 같은 고독한 프로그래머에게는 소스 제어는 코드를 개발하고 판매하는 실제 돈 버는 활동을 지원하는 데 드는 비용입니다. 고려해야 할 몇 가지 요소가 있습니다.

• 개발 모델에 얼마나 잘 맞습니까?
• 개발자가 배우고 사용하는 것이 얼마나 쉬운가요?
• 개발자를위한 일상적인 작업이 빠릅니까?
• 코드를 작성하는 것이 실제 작업에서 방해가 되는가?
• 설치 및 유지 관리가 얼마나 쉬운가요?
• 구매 및 유지 비용은 얼마입니까?
• 도움이 필요하면 얼마나 쉬운가요?

개별 시스템의 장단점에 대한 tl : dr 세부 사항은 생략하겠습니다. 작년에 풀 타임 컨설팅으로 돌아 왔을 때, 나는 고객에게 양질의 소프트웨어를 제공함으로써 많은 돈을 들이지 않고도 최대한 빨리 돈을 벌 수있는 방법을 결정하기 위해 세 가지를 모두 검토했다. 장난. 나는 "FOSS가 좋고 FOSS가 아닌 것이 악"이라는 정치적 고려를 빼고 Perforce 라이센스를 포기했다.

그래서 대기업도 Perforce를 선택합니다.

다음은 주석의 tl : dr 세부 정보와 약간 더 있습니다.

svn을 해결하는 것은 쉽습니다. Perforce와 비교할 때 개 속도가 느립니다. 휴대 전화 용 Linux를 내장 한 회사에서 근무했으며 전체 소스는 9GB였습니다. 그들은 Perforce를 사용했습니다. 코드를 가지고 나면 최신 소스를 업데이트하는 데 일반적으로 LAN에서 몇 초가 걸리거나 내 집의 VPN 연결을 통해 몇 분이 걸렸습니다. svn을 사용하면 각각 분과 시간이었습니다.

자식 대 퍼 포스가 더 복잡합니다. 많은 회사는 액세스 제어 기능이있는 중앙 집중식 리포지토리를 사용하고 쉽게 커밋하고 다른 작업을 수행하기 어려운 비즈니스상의 이유가 있다고 생각합니다. Perforce는 해당 모델에 완벽하게 맞습니다. 그러나 git은 사람들이 현지 지사에서 일할 것을 적극적으로 권장하며 다른 방식으로 일할 수있는 방법이 없습니다. 개발자는 전적으로 현지 지사에서 일할 수 있으며 중앙 리포지토리에 전념 할 수 없습니다. 따라서 회사에서 직원이 그런 식으로 일하는 것을 원하지 않으면 Perforce가 더 나은 옵션입니다.

일부 비즈니스 요구에 대한 git에는 다른 문제가 있습니다. 나는 git을 사용하는 회사에서 일을했는데이 토론을 몇 번이나 들었는지 모른다. " "물론 git으로 할 수 있습니다." "어떻게?" "먼저 bash 스크립트를 작성해야합니다 ..."

그리고 많은 히스토리가있는 소스 트리를 초기화하는 데 걸리는 시간이 있습니다. Perforce를 사용하면 기록이 서버에 유지되므로 모든 파일의 최신 버전을 얻을 수 있으므로 정말 빠릅니다. 언급 한 전체 9GB 트리를 설정하는 데 VPN을 통해 몇 시간 밖에 걸리지 않았습니다. git을 사용하면 오랜 시간과 영원이 걸릴 수 있습니다. 때때로 GTK + 또는 X 서버 git repos를 복제해야합니다. 점심 시간이 길거나 잠자리에 드는 시간 일 수도 있습니다.

실제로, 그것은 작업에 적합한 도구의 문제입니다. svn은 대부분의 Apple 오픈 소스 노력에 적합하며 커널 해킹에는 끔찍합니다. git은 GTK +에서는 훌륭하게 작동하지만 WebKit 내부에서 작업하기에는 엄청나게 느립니다. 소스 트리와 히스토리는 너무 큽니다 (WebKit의 svn-to-git 포털에서 코드로 작업하는 어려운 방법을 알았으므로). 거대한 소스 트리가 있고 중앙 집중식 제어가 필요한 경우 Perforce가 잘 작동합니다. 그들 각각은 올바른 상황에서 잘 작동합니다.

특히 GIT과 SVN은 그다지 오래되지 않았습니다 .90 년대 중반에 견고한 버전 제어가 필요하다면 SVN이 초기 단계에 있었고 CVS는 CVS이기 때문에 거의 상용화해야했습니다. 시스템에 많은 투자를 한 후에는 시스템을 옮기는 것이 곰이 될 수 있습니다.

아, 그리고 이러한 결정을 내리는 사람들은 아마도 버전 관리 시스템과 상호 작용하지 않지만 앞서 언급 한 영업 직원에 의해 와인을 마시고 식사를하지 않습니다.

저는 거의 9 년 동안 게임 업계에서 프로그래머로 일해 왔으며, 제가 작업 한 모든 프로젝트는 Perforce를 사용했습니다. 특정 산업에서 Perforce를 계속 사용하는 것이 몇 가지 있다고 생각합니다.

• 사람들은 오랫동안 Perforce를 사용해 왔으며 그에 익숙하여 다른 솔루션으로 전환하는 것을 주저합니다. 의사 결정자들은 이전에 사용하지 않은 소프트웨어를 통해 3 천만 달러 프로젝트를 주저 할 수도 있습니다.
• 많은 회사 / 팀이 사내 도구에 Perforce 지원을 추가했습니다. 다른 VCS를 지원하기 위해 업데이트하려면 상당한 양의 작업이 필요할 수 있습니다.
• 프로그래머가 다른 Git / Hg / SVN으로 쉽게 전환 할 수 있지만 아티스트, 디자이너 및 프로듀서와 같은 게임 개발 팀의 기술 구성원은 많지 않습니다. 새로운 시스템에 익숙해 지려면 많은 시간이 걸릴 수 있으며 변경 사항에 상당히 저항 할 수 있음을 확신합니다.

어쩌면 퍼 포스가 더 좋기 때문에 퍼 포스를 좋아할까요?

• 퍼 포스가 빠릅니다. Subversion 또는 Git보다 훨씬 빠릅니다.
• Perforce 병합은 Subversion 또는 Git보다 낫습니다. Git은 실제로 병합을 수행하지 않으며 Subversion의 버전 추적은 적어도 1.5에서는 그리 좋지 않습니다.
• Perforce는 탁월한 고객 지원을 제공합니다.
• Perforce는 Subversion의 리포지토리 개정 과 개별 파일 개정을 결합합니다. Perforce에서는 변경 목록 또는 개별 파일 개정을 통해 저장소 개정을 볼 수 있습니다 .
• Perforce는 Subversion보다 여러 변경 목록을 사용하는 것이 훨씬 좋습니다. Subversion의 변경 목록은 다소 나중에 생각할 수 있으며 누가 그것을 사용하는지 거의 알지 못합니다. Perforce가 내장되어 있습니다. 기본 변경 목록에서 변경된 파일을 이동해도 실수로 커밋되지 않습니다.
• Perforce에서는 작업 디렉토리 레이아웃을 지정할 수 있습니다. 예를 들어 표준 소스 코드 디렉토리 트리가 있지만 일부 고객은 사용자 정의 소스가있는 경우 표준 트리 위에 사용자 정의 소스를 오버레이 할 수 있습니다. 체크 아웃하려는 항목 만 지정하여 스파 스 체크 아웃을 쉽게 수행 할 수 있습니다.

좋아, 내가 Perforce Fanboi라고 생각하기 전에, 내가 회사에 Perforce를 마지막으로 추천 한 것은 7 년 전이었습니다. Perforce는 라이센스 당 800 달러로 ClearCase에 비해 저렴하지만 Subversion에 비해 비용이 많이 듭니다. Perforce over Subversion을 정당화하는 데 어려움을 겪고 있습니다.

또한 대부분의 개발자는 Subversion을 사용합니다. 그들은 Subversion과 다른 작업 방식을 가진 Perforce를 배우고 싶지 않습니다. Perforce에서는 클라이언트 를 작성 해야하며 수정하기 전에 편집 할 파일을 표시해야합니다. Subversion을 사용하지 않아도됩니다.

Perforce over Subversion과의 통합도 적습니다. 그 중 일부는 클라이언트를 사용하기 때문 입니다. VisualStudio 또는 Hudson에서도 잘 작동하지 않습니다. Perforce가 클라이언트 통합을 작성해야하기 때문입니다.

독점 라이센스 비용으로 관리 비용이 발생합니다. 사용자 당 1.00 달러에 소프트웨어를 라이센스 할 수 있다고 상상해보십시오. 도대체 2 비트로 만들어 봅시다. 수천 개의 라이센스는 250 달러에 불과합니다.

이제 라이센스를 관리하는 정규 직원이 필요합니다. 평범한 기술 직원은 약 2 년 동안 회사에 머물러 있습니다. 즉, 매년 500 명이 떠나고 또 500 명이 올 것입니다. 매주 10 명씩 라이센스를 변경해야합니다. 그런 다음 프로젝트가 시작되고 250 개의 라이센스가 더 필요할 때가 있습니다. 주문, 입력 및 유지 보수가 필요합니다. 몇 주가 걸릴 수 있습니다.

많은 상업 회사가 오픈 소스로 전환 한 이유입니다. 라이센스 비용이 아닙니다. 개발자에게 매년 $ 150,000를 지불하면 Perforce 라이센스에 대해 $ 800가 추가됩니까? 그 라이센스를 관리하고 있습니다. Perforce는 ClearCase와 비교할 때 멋지게 보입니다. 더 빠르고, 쉽고, 저렴하며, 더 좋습니다. 그러나 Subversion에 대해? 퍼 포스가 더 빠를 수도 있고 더 좋을 수도 있지만 800 달러가 더 낫습니까? 라이센스를 더 잘 관리합니까? 원하는 도구를 더 잘 사용하지 않습니까?

그래서 Perforce에 문제가있을 수 있습니다.

힘내가 전부가 아니다. 리포지토리에 대한 액세스 권한이있는 사람을 중앙에서 제어하지 않으려는 경우에 효과적입니다. 그러나 많은 상황에서 고통이 될 수 있습니다. 내가 넣는 방식은 다음과 같습니다.

1. 오픈 소스 프로젝트를 실행합니다. 백만 명의 사람들이 전체 저장소의 사본을 가지고 있다면 행복합니까?
2. 독점 소프트웨어를 사용하여 경쟁 업체와 우위를 점하는 금융 거래 데스크를 운영하고 있습니다. 백만 명의 사람들이 전체 저장소의 사본을 가지고 있다면 행복합니까?

중앙 집중식 빌드를 수행하는 경우 모든 사람이 단일 저장소를 사용해야합니다. 이 상황에서 분산 시스템의 장점은 무엇입니까? 실제로 사람들이 오프라인 으로 작업하도록 장려 할 수 있습니다 . 개발자는 단순히 자신의 즐거운 길을 떠나 마지막 순간까지 아무것도 저 지르지 않을 수 있습니다. 그런 다음 모든 것을 다시 작동 시키려고 열렬한 이틀을 보냅니다.

나는 Git에 반대하지 않는다. 많은 경우 Git을 추천했습니다. 여기에는 서로 연결이 불량한 분산 팀 또는 소스 리포지토리에 액세스 할 수있는 모든 사람을 추적하지 않는 장소가 포함됩니다.

예를 들어, 한 대학의 컴퓨터 과학 부서는 학생들이 소스 제어를 사용하도록하고 교사가 볼 수 있도록 코드를 작성하려고했습니다. 좋은 생각이야 표준 구축 및 개발 절차를 이해하지 못한 채 너무 많은 어린이가 대학을 떠납니다. 나는 Git을 추천했다.

Git을 사용하면 저장소 관리자는 동료 교수의 커밋 만하면됩니다. 그들은 개별 학생에 대해 걱정할 필요가 없습니다. 교수는 학생들이 자신의 저장소 버전에 커밋하도록 허용 할 수 있습니다. 학생들은 그룹으로 작업 할 수 있으며 각 그룹은 자신의 저장소 버전을 공유 할 수 있습니다.

만약 대학이 Subversion을 사용했다면, 누군가는 모든 학생들을 알고 중앙 저장소에 대한 모든 접근을 제공해야 할 것입니다. 누가 어디서 무엇을 체크인 할 수 있는지 관리해야합니다. 교수가 그룹 프로젝트를 배정한 경우이를 설정하고 관리해야합니다. 당신은 그것을 관리하기 위해 풀 타임 사람이 필요합니다.

이것은 한 팀이 다른 팀보다 나은 축구 게임이 아닙니다. 도구는 다른 방식으로 작동하며 각각의 장단점이 있습니다. Perforce는 훌륭한 도구입니다. 불행히도, 권장하기 어려운 상황이 개발되었습니다.

Git은 훌륭하지만 개인 소스 저장소의 Subversion으로 계속 넘어갑니다. 결국, 나는 그것을 공유하지 않으며 Subversion은 사용하기가 더 쉽습니다. 소규모 팀이있는 경우 Git을 개인 작업에 사용합니다. 인터넷에서 항상 리포지토리를 유지할 필요가 없기 때문입니다. 대부분의 상업용 사이트에서 여전히 Subversion이 가장 효과적이라는 것을 알았습니다. 그러나 Git이 빛나는 상황이 있습니다.

'와인과 식사'뇌물이 여전히 적용 가능한지 모르겠지만, 대부분의 관리자는 제품을 찾을 때 다양한 간행물 (관리 대상)을 읽고 제품을 홍보하는 팜플렛 및 팜플렛을 볼 것입니다 미덕.

그 장소에 FOSS 제품이없는 것이 무엇인지 맞춰보세요!

따라서 대부분의 경영 구매 결정은 광고 및 마케팅에 의해 결정됩니다. 평가를 수행 할 수 있지만 이러한 제품 중 일부를 평가할 수 있습니다.

다른 이유는 성숙 때문입니다. 오늘날 우리가 사용하는 일부 제품은 최근에 심각한 비즈니스 용도로 사용하기에 충분히 안정적이며 일부는 지원 옵션이 없으며 일부는 비즈니스 솔루션으로 입증 된 실적이 없습니다. 고려해야 할 중요한 사항입니다 (기술자가 FOSS 솔루션을 사용하고 실패해도 비즈니스 운영을 유지하는 데 최소한의 위험이있는 경우 기꺼이 FOSS 솔루션을 평가할 것이지만). 그들은 상사에게 책임이 있으며 제품 뒤에 지원 조직이 있으면 훨씬 더 편안하게 느낄 것입니다. 결국 비즈니스를위한 조직이 있습니다.

마지막으로, 많은 FOSS 제품이 SVN을 지원하지만 Collabnet 또는 Wandisco는 SVN이라고 생각합니다. 우리 모두는 일반적으로 b * * ** t이며 최고의 FOSS는 상업용 제품과 엄청나게 잘 경쟁하지만 관리자는 여전히 확신해야합니다. 아마도 그는 미성숙 한 FOSS 제품과 성숙한 FOSS 제품의 차이점을 깨닫지 못할 수도 있습니다. 아마 상관 없어요

어쨌든 Perforce는 훌륭한 SCM이므로 선택하지 않을 이유가 없습니다. 나는 다른 SCM들에게도 똑같이 말할 수 있지만, 다시 말하지만, 일부 다른 제품에 대해서는 나쁜 말만 할 수 있으며 특정 제품에 관해서는 악몽이 있습니다.

Perforce와 같은 도구는 세일즈맨에게 와인을 구매하고 구매 담당자를 먹어야하지만 Git은 그렇지 않습니다. 물론, 그것은 저의 냉소적 인면에 불과하지만 그 과정을 가까이서 보아온 냉소주의입니다.

완벽하게 명확하게하기 위해서 : CIO가 복도를 뒤죽박죽으로 볼 때마다 다음 분기에 새로운 버전 관리 시스템을 사용할 것으로 기대하는 것은 아닙니다 . 많은 조직에서 사용과 취득 사이에 연결이 끊어 졌다는 것만으로도 물론 회사가 Perforce를 사용하는 다른 이유도 있습니다. 예를 들어, 회사는 이미 워크 플로 구현에 막대한 투자를했을 수 있습니다. 그러나 일반적으로이 질문은 매우 일반적입니다. FOSS 도구를 사용하지 않으면 기능상 이점이 없습니다.

아마도 회사에서 많은 오픈 소스 소프트웨어 사용을 거부하는 것과 같은 이유 일 것입니다 (동의하지 않음).

문제가 발생하면 전화를 걸고 소리를지를 수있는 사람을 원합니다.

모든 답변은 P4를 사용하는 대기업에 대해 이야기하지만 Google이 P4를 사용하는 이유에 답변합니다 .Google이 Perforce를 계속 사용하는 주된 이유 중 하나는 Perforce를 사용하여 리포지토리의 하위 트리를 체크 아웃 할 수 있지만 Git으로는 그렇게 할 수 없기 때문입니다. 구글과 같은 큰 소스 리포지토리로 큰 차이를 만들었습니다.

그리고 내가 들었던 한 Facebook은 SVN과 Git-SVN을 사용합니다.

SVN은 SVN과 Perforce (도구를 비교할 때 4 년 전부터) 가 SVN보다 더 나은 일을하기 때문 입니다. (분기 중 하나는 내가 생각하는 것 중 하나입니다.)

같이 그리고 GIT는 DVCS입니다 분산 . 회사 팀의 경우 분산 된 부분은 관심도없고 원하지 않는 것일 수도 있습니다.

대기업이 대기업, "기업"버전 제어 시스템을 구매하는 또 다른 이유는 다음과 같습니다.

IT 부서의 중급에서 최고 경영진은 VCS를 모든 단일 프로젝트가 사용하는 것으로 간주하거나 사용을 강제 할 수 있습니다. 일단 VCS를 사용하도록 강요했다면 거기에 "프로세스"를 넣지 않겠습니까? "엔터프라이즈 전체"시스템을 지정할 수있는 기회가 있으며, 중앙 제어하에 시스템을 설치하고 "재해 복구"및 "워크 플로 기능"을 추가하여 "CMM Level StraightJacket"이라고 말할 수 있습니다. 호환! " VCS는 워크 플로우 강화 기능을 제공하기에는 너무 쉬운 목표입니다.

바쁘고 푸짐한 소프트웨어 (Serena Dimensions)를 선택하는 한, 여성 판매 직원이 20 명인 바하마에있는 몇 차례의 비키니 골프는 이사 나 부사장에게 거의 모든 것을 설득 할 수 있다고합니다.

대기업에는 어떤 종류의 중앙 집중식 모델이 필요합니다. 개발자가 개발을 마치면 고객 지원 부서로 전달됩니다. 50-200 개의 분산 된 개발자 저장소를 통해 빗질해야 할 때 지원 신발을 착용하고 싶습니까? 그리고 빌드는 중앙 저장소를 기반으로 수행되며 빌드는 항상 추적 가능하고 재현 가능해야합니다. 처음으로 바보 같은 특허 침해에 대해 법정에 출두 할 때 이것을 배웁니다.

이 모델에서는 Git이 제대로 작동하지 않습니다. 소규모 회사 또는 VPN 액세스 권한이없는 회사가 있다면 바로 그 곳입니다.

대부분의 대기업에서 Perforce를 사용하는 한 가지 이유는 IT 부서에 많은 지식을 갖고 있고 수년 간의 문제 해결 경험이있는 전문가가 더 많기 때문일 수 있습니다.

나는 미래에 회사가 Perforce에서 벗어나 GIT로 나아 가기 시작할 것이라고 생각합니다. Perforce가 향후 몇 년간 지배적이지 않은 이유에 대한 추가 증거는 http://whygitisbetterthanx.com/#git-is-fast 를 확인 하십시오 !

몇 번 전에, 우리는 VCS (RCS, CVS, ClearCase, Perforce가 이전에 사용되었고 다른 것도있을 수 있음)에서 사용중인 고유 시스템으로 Perforce로 전환했습니다. 소규모 프로젝트는 아니 었습니다. 마이그레이션에 1 년이 걸렸습니다. 담당 팀 (나는 그것의 일부가 아니었다)은 여러 VCS를 평가했으며 적어도 git 및 svn은 이미 사용중인 것뿐만 아니라 고려되었습니다. 보고서를 기억하면서 필요한 기능없이 도구를 필터링 한 후 다음을 고려했습니다.

• 원격 사이트의 일반적인 사용 성능

• 자원 요구 사항

• 작업 습관에 필요한 변화의 중요성

• 가용성 및 비용 지원

퍼 포스는 전반적으로 확실한 승자였습니다. git은 첫 번째 점에서 약간 더 좋았지 만 다른 점에서는 불리했습니다.

옛날에, 그리 오래 전 합니다 (IDE는 VI 호출 될 때), 유일한 무료 (오픈 소스) 시스템은 CVS, RCS와 SCCS이었다.

• 이들 중 어느 것도 이름이 바뀌는 파일에 잘 대처할 수 없었습니다.
• 그들은 합병을 기록하지 않았기 때문에 두 개의 지점이 활발히 작업 중이라면 한 지점에서 작업이 완료 될 때까지 병합하기가 매우 어려웠습니다.
• 그들은 매우 큰 코드 기반으로 확장되지 않았습니다
• 그들은 대규모 프로젝트가 원하는 수준의 액세스 제어 및 프로세스 정보를 제공하지 않았습니다.

상용 소스 코드 제어 시스템이 많이 있었으며 대부분 단일 기계 공급 업체 (IBM, DEC, HP 등)가 제공했으며 하드웨어에서만 실행되었습니다.

그런 다음 일부 회사는 Perforce 및 ClearCase를 포함한 플랫폼 간 상용 소스 코드 제어를 판매한다고 언급했습니다.

ClearCase는 RPC를 기반으로 구축 되었기 때문에 많은 소규모 네트워크 패킷이 "둥근 트립"되어 넓은 영역 네트워크 (인터넷은 아님)에서는 제대로 작동하지 않았으며 IBM과 합리적 ClearCase는 "캐쉬 카우"로 보지 않았으며 많은 것을 보여주지 않았습니다. 사랑.

따라서 여전히 보편적으로 사용되는 유일한 "오래된"상용 소스 코드 제어 시스템은 Perforce입니다. 일단 perforce를 사용하고 빌드 시스템 및 버그 추적 시스템에 통합 한 후에 는 회사가 다른 곳으로 옮길 수있는 단기적인 이점이 거의 없습니다.

요약하자면, perforce는 다른 옵션이 많지 않았을 때“발판”을 얻었고 사람들은 아직 멀어지지 않았습니다 .