Tại sao các công ty lớn sử dụng Perforce? [đóng cửa]

Tôi đã nghe nói về một số công ty lớn, ví dụ Google, Facebook sử dụng Perforce

Có bất kỳ lý do tại sao SVN / Git không thể thay thế Perforce không?

Sự biện minh có lẽ ít liên quan hơn trước đây, nhưng Perforce có xu hướng hoạt động tốt hơn trên các kho lưu trữ lớn hơn Subversion. Đây là một trong những lý do Microsoft mua giấy phép nguồn cho Perforce để xây dựng Source Depot; Kho lưu trữ của NT là một con quái vật, và không nhiều sản phẩm, thương mại hay mặt khác, có thể xử lý nó.

Ngoài ra, ít nhất tại một thời điểm, các công cụ trực quan cho Perforce là cách, tốt hơn so với những gì có sẵn trong hộp (có thể nói) với Subversion hoặc Git. Nếu bạn đang sử dụng Meld có lẽ những điều đó ít quan trọng hơn trước đây, nhưng vẫn có một vài điều mà Perforce đã làm rất độc đáo, bao gồm trực quan hóa việc phân nhánh và hợp nhất, mặc dù tôi không có bộ nhớ chi tiết về nó. khoảng 3 năm kể từ lần cuối tôi chạm vào Perforce, dường như tinh vi hơn, ví dụ, cách tiếp cận của Github với điều đó.

Khi bạn đã sử dụng Perforce, bạn có thể hiểu những lợi thế của nó trong thực tế. Từ lâu họ đã cung cấp tùy chọn máy chủ hai người dùng miễn phí và tùy thuộc vào hệ thống quản lý mã nguồn mà bạn có kinh nghiệm, bạn có thể thấy nó đáng để nâng cấp sau khi nhóm của bạn kiểm tra một lúc. Đối với các cửa hàng nhỏ hơn, điều này, cộng với hiệu ứng mạng của các nhà phát triển đã sử dụng và thích nó, là lý do tại sao Perforce kết thúc việc trả tiền cho người dùng. Có lẽ không có nhiều hoạt động ăn uống và ăn CTO để bán Perforce tại các công ty có đội ngũ phát triển nhỏ, trái ngược với nhận xét cay độc của Dmitri, nhưng nó được sử dụng ở những nơi như vậy.

Hầu hết các dự án tôi từng làm việc bên ngoài Microsoft có thể được Git, Mercurial hoặc Subversion phục vụ một cách hợp lý và tôi nói rằng phần lớn các công ty tôi từng làm việc sử dụng một trong những tùy chọn đó. Nhưng có một điểm hay, thường là sự kết hợp giữa kích thước kho lưu trữ, mô hình phân nhánh và hợp nhất và kinh nghiệm / lịch sử nhóm dẫn mọi người sử dụng các công cụ thương mại. Tôi hiếm khi thấy các kho Git lớn, ví dụ. Điều này có thể không phải do bất kỳ giới hạn nội tại nào của Git; Tôi thừa nhận hoàn toàn không biết gì về điều đó. Nhưng trong một số dự án (như Windows NT) có thể có một số giới hạn thực tế đối với các giải pháp miễn phí.

Tôi khá thành thạo với svn, git và Perforce, cả với tư cách là người dùng và thiết lập và bảo trì máy chủ.

Đối với một công ty, hoặc thậm chí là một lập trình viên đơn độc như tôi, kiểm soát nguồn là chi phí phát sinh để hỗ trợ cho hoạt động kiếm tiền thực sự, đang phát triển và bán mã. Vì vậy, có một số yếu tố để xem xét:

• Làm thế nào nó phù hợp với mô hình phát triển của bạn?
• Làm thế nào dễ dàng cho các nhà phát triển để tìm hiểu và sử dụng?
• Là hoạt động thường xuyên cho các nhà phát triển nhanh chóng?
• Là quá trình sử dụng nó là một sự phân tâm từ công việc thực sự của họ, đó là viết mã?
• Làm thế nào dễ dàng để thiết lập và bảo trì?
• Chi phí mua và bảo trì là bao nhiêu?
• Nếu bạn cần giúp đỡ, làm thế nào dễ dàng để có được nó?

Tôi sẽ bỏ qua chi tiết tl: dr về ưu và nhược điểm của từng hệ thống. Đủ để nói rằng khi tôi quay lại tư vấn toàn thời gian vào năm ngoái, tôi đã xem xét cả ba để quyết định sẽ cho phép tôi kiếm được nhiều tiền nhất có thể bằng cách cung cấp phần mềm chất lượng cho khách hàng của mình và không yêu cầu nhiều khoản phải trả đánh lừa xung quanh. Khi tôi cân nhắc chính trị về "FOSS là tốt và không phải FOSS là xấu xa", tôi đã cố gắng xin giấy phép Perforce.

Và đó là lý do tại sao các công ty lớn cũng chọn Perforce.

Dưới đây là chi tiết tl: dr từ các bình luận, cộng thêm một chút nữa.

Địa chỉ svn rất dễ: so với Perforce, nó chậm như chó. Tôi đã làm việc tại một công ty đã nhúng Linux cho điện thoại di động và các nguồn hoàn chỉnh của chúng tôi chạy được 9 GB; họ đã sử dụng Perforce. Khi bạn đã có mã, việc cập nhật các nguồn mới nhất thường mất vài giây trên mạng LAN hoặc vài phút qua kết nối VPN từ nhà tôi. Với svn, nó sẽ có phút và giờ tương ứng.

git so với Perforce thì phức tạp hơn. Nhiều công ty cảm thấy họ có lý do kinh doanh tốt để sử dụng kho lưu trữ tập trung có kiểm soát truy cập và để dễ dàng cam kết ở đó và khó có thể làm bất cứ điều gì khác - và Perforce hoàn toàn phù hợp với mô hình đó. Tuy nhiên, git tích cực khuyến khích mọi người làm việc trong một chi nhánh địa phương, và không có cách nào để làm cho nó hoạt động khác đi. Một nhà phát triển có thể làm việc hoàn toàn trong một chi nhánh địa phương và không bao giờ cam kết với repo trung tâm - vì vậy nếu một công ty không muốn mọi người làm việc theo cách đó, Perforce là một lựa chọn tốt hơn.

Có những vấn đề khác với git cho một số nhu cầu kinh doanh. Tôi đã làm việc tại một công ty sử dụng git và tôi không biết mình đã nghe cuộc thảo luận này bao nhiêu lần: "Tôi ước chúng tôi đang sử dụng [một số VCS khác], vì tôi cần làm [điều này] và tôi không thể với git . " "Tất nhiên bạn có thể làm điều đó với git." "Làm sao?" "Chà, trước tiên bạn cần viết một kịch bản bash ..." "Đừng bận tâm."

Và sau đó là thời gian cần thiết để khởi tạo một cây nguồn có nhiều lịch sử. Với Perforce, vì lịch sử được lưu giữ trên máy chủ, bạn chỉ cần nhận các phiên bản mới nhất của tất cả các tệp, vì vậy nó rất nhanh - thậm chí thiết lập toàn bộ cây 9 GB mà tôi đã đề cập chỉ mất vài giờ qua VPN. Với git, nó có thể mất một nơi nào đó giữa một thời gian dài và vĩnh cửu. Đôi khi tôi phải sao chép GTK + hoặc máy chủ X git repos và đó là thời gian nghỉ trưa dài, hoặc có thể là thời gian đi ngủ.

Thực sự, đó là vấn đề của công cụ phù hợp cho công việc. svn hoạt động tốt đối với hầu hết các nỗ lực nguồn mở của Apple và sẽ rất tệ cho việc hack kernel. git hoạt động rất tốt cho GTK +, nhưng cực kỳ chậm khi hoạt động bên trong WebKit - cây nguồn và lịch sử quá lớn (như tôi đã tìm ra cách làm việc khó khăn với mã từ cổng svn-to-git của WebKit). Perforce hoạt động tốt nếu bạn có một cây nguồn khổng lồ và cần kiểm soát tập trung. Mỗi người trong số họ làm việc tốt trong bối cảnh đúng.

Đặc biệt là GIT và SVN ở một mức độ nào đó không phải là cũ - nếu bạn cần kiểm soát phiên bản vững chắc vào giữa những năm 90, bạn gần như phải đi thương mại vì SVN còn ở giai đoạn sơ khai và CVS cũng vậy, CVS. Khi bạn đã đầu tư rất nhiều vào một hệ thống, việc di chuyển nó có thể là một con gấu.

Ồ, và những người đưa ra các quyết định này có thể không bao giờ tương tác với hệ thống kiểm soát phiên bản nhưng lại bị phạt và ăn tối bởi các nhân viên bán hàng đã nói ở trên.

Tôi đã là một lập trình viên trong ngành công nghiệp trò chơi gần 9 năm nay và mọi dự án tôi từng làm đều sử dụng Perforce. Tôi nghi ngờ rằng có một vài điều giữ Perforce được sử dụng trong ngành công nghiệp cụ thể đó.

• Mọi người đã sử dụng Perforce trong một thời gian dài và khá thoải mái với nó, khiến họ ngần ngại chuyển sang một giải pháp khác. Những người ra quyết định cũng có thể do dự khi đặt dự án 30 triệu đô la của họ vào tay phần mềm mà họ chưa từng sử dụng trước đây.
• Nhiều công ty / nhóm đã thêm hỗ trợ Perforce vào các công cụ nội bộ của họ, có thể cần một lượng công việc đáng kể để cập nhật để hỗ trợ một VCS khác.
• Mặc dù các lập trình viên có thể dễ dàng chuyển sang một Git / Hg / SVN khác, có rất nhiều thành viên ít kỹ thuật của một nhóm phát triển trò chơi, chẳng hạn như các nghệ sĩ, nhà thiết kế và nhà sản xuất. Làm cho họ thoải mái với hệ thống mới có thể mất rất nhiều thời gian và tôi sẵn sàng cá rằng họ sẽ khá chống lại sự thay đổi.

Có lẽ, có lẽ họ thích Perforce vì Perforce tốt hơn?

• Lực lượng là nhanh chóng. Nhanh hơn nhiều so với Subversion hoặc Git.
• Hợp nhất Perforce tốt hơn Subversion hoặc Git. Git không thực sự hợp nhất và theo dõi phiên bản của Subversion không tốt lắm, ít nhất là trong 1.5.
• Perforce có hỗ trợ khách hàng tuyệt vời.
• Perforce kết hợp sửa đổi kho lưu trữ của Subversion với sửa đổi tệp riêng lẻ. Perforce cho phép bạn xem các bản sửa đổi kho lưu trữ thông qua danh sách thay đổi hoặc bản sửa đổi tệp riêng lẻ.
• Perforce thực hiện công việc tốt hơn nhiều với nhiều danh sách thay đổi so với Subversion. Thay đổi của Subversion là một phần của suy nghĩ và tôi biết ít người sử dụng nó. Perforce được tích hợp sẵn. Nếu bạn di chuyển một tệp đã thay đổi từ danh sách thay đổi mặc định, nó sẽ không bị vô tình phạm phải.
• Perforce cho phép bạn chỉ định bố cục thư mục làm việc của bạn. Ví dụ: nếu bạn có cây thư mục mã nguồn tiêu chuẩn, nhưng một số khách hàng có nguồn tùy chỉnh, bạn có thể phủ nguồn tùy chỉnh lên trên cây tiêu chuẩn. Bạn có thể dễ dàng thực hiện kiểm tra thưa thớt bằng cách chỉ định những mục bạn muốn kiểm tra.

Được rồi, trước khi bạn nghĩ tôi là một Perbo Fanboi, lần cuối cùng tôi giới thiệu Perforce cho một công ty là hơn bảy năm trước. Perforce có giá 800 USD mỗi giấy phép - rẻ so với ClearCase, nhưng đắt hơn khi so với Subversion. Tôi có một thời gian khó khăn để biện minh cho Perforce trên Subversion.

Thêm vào đó, hầu hết các nhà phát triển đang sử dụng để Subversion. Họ không muốn học Perforce có cách làm việc khác với Subversion. Trong Perforce, bạn phải tạo một ứng dụng khách và bạn phải đánh dấu các tệp để chỉnh sửa trước khi bạn có thể sửa đổi chúng. Bạn không cần phải làm điều đó với Subversion.

Có ít tích hợp hơn với Perforce trên Subversion. Một phần là do việc sử dụng của khách hàng . Nó chỉ không chơi tốt với VisualStudio hoặc thậm chí Hudson. Một phần của nó là do thực tế là Perforce phải tạo ra các tích hợp máy khách.

Có một chi phí để giấy phép độc quyền gọi chi phí hành chính. Hãy tưởng tượng nếu bạn có thể cấp phép cho một phần mềm với giá $ 1 mỗi người dùng. Heck, hãy làm cho nó hai bit. Một ngàn giấy phép sẽ chỉ tốn 250 đô la.

Bây giờ, bạn cần một người toàn thời gian quản lý giấy phép. Một công nhân kỹ thuật trung bình ở quanh một công ty trong khoảng 2 năm. Điều đó có nghĩa là 500 người mỗi năm sẽ rời đi và 500 người khác sẽ đến. Mười người mỗi tuần phải thay đổi giấy phép. Sau đó, có những lúc dự án chọn và bạn cần thêm 250 giấy phép. Những người phải được ra lệnh, nhập và duy trì. Điều đó có thể mất vài tuần.

Đó là lý do tại sao nhiều công ty thương mại đã chuyển sang nguồn mở. Đó không phải là chi phí của một giấy phép. Bạn phải trả cho nhà phát triển 150.000 đô la mỗi năm, còn 800 đô la nữa cho giấy phép Perforce? Đó là quản lý giấy phép đó. Perforce trông tuyệt vời khi so sánh với ClearCase: Nhanh hơn, dễ dàng hơn, rẻ hơn, tốt hơn. Nhưng, chống lại lật đổ? Perforce có thể nhanh hơn và có thể tốt hơn, nhưng nó có tốt hơn $ 800 không? Là nó quản lý giấy phép tốt hơn? Có phải nó không sử dụng một công cụ mong muốn tốt hơn?

Đó là lý do tại sao Perforce có thể gặp vấn đề.

Git không phải là công cụ kết thúc tất cả. Nó hoạt động rất tốt trong trường hợp bạn không muốn kiểm soát tập trung những người có quyền truy cập vào kho lưu trữ. Nhưng, nó có thể là một nỗi đau trong nhiều trường hợp. Cách tôi đặt nó là theo cách này:

1. Bạn chạy một dự án nguồn mở. Bạn sẽ vui hay buồn nếu một triệu người có một bản sao của toàn bộ kho lưu trữ của bạn?
2. Bạn đang điều hành một bàn giao dịch tài chính sử dụng phần mềm độc quyền để có lợi thế với các đối thủ cạnh tranh. Bạn sẽ vui hay buồn nếu một triệu người có một bản sao của toàn bộ kho lưu trữ của bạn?

Nếu bạn đang thực hiện các bản dựng tập trung, bạn vẫn cần mọi người sử dụng một kho lưu trữ duy nhất. Lợi thế của một hệ thống phân tán trong trường hợp này là gì? Trong thực tế, nó có thể khuyến khích mọi người làm việc ngoài luồng . Các nhà phát triển có thể đơn giản đi theo cách vui vẻ của riêng họ và không cam kết bất cứ điều gì cho đến phút cuối cùng. Sau đó, bạn dành hai ngày điên cuồng để cố gắng làm mọi thứ hoạt động trở lại.

Tôi không chống lại Git. Tôi đã đề nghị Git trong nhiều trường hợp. Chúng bao gồm các nhóm phân phối có kết nối kém với nhau hoặc những nơi bạn không muốn theo dõi tất cả những người có quyền truy cập vào kho lưu trữ nguồn.

Ví dụ, một bộ phận khoa học máy tính của trường đại học muốn cho sinh viên của họ sử dụng kiểm soát nguồn và đặt mã của họ ở đó để giáo viên xem xét. Ý tưởng tuyệt vời. Quá nhiều trẻ em rời khỏi trường đại học mà không hiểu các quy trình xây dựng và phát triển tiêu chuẩn. Tôi đề nghị Git.

Bằng cách sử dụng Git, quản trị viên của kho lưu trữ chỉ phải nhận các cam kết từ các giáo sư đồng nghiệp của họ. Họ không phải lo lắng về từng học sinh. Các giáo sư có thể cho phép sinh viên cam kết với phiên bản kho lưu trữ của họ. Học sinh có thể làm việc theo nhóm và mỗi nhóm có thể chia sẻ phiên bản kho lưu trữ của họ.

Nếu trường đại học sử dụng Subversion, ai đó sẽ phải biết tất cả các sinh viên và cung cấp cho họ tất cả quyền truy cập vào kho lưu trữ trung tâm. Họ phải quản lý ai có thể kiểm tra cái gì và ở đâu. Nếu một giáo sư chỉ định một dự án nhóm, đó sẽ phải được thiết lập và quản lý. Bạn sẽ cần một người toàn thời gian chỉ để quản lý điều đó.

Đây không phải là một trò chơi bóng đá trong đó một đội tốt hơn một đội khác. Các công cụ hoạt động theo những cách khác nhau và mỗi cách đều có ưu điểm và nhược điểm. Perforce là một công cụ tuyệt vời. Thật không may, hoàn cảnh đã phát triển mà làm cho nó khó để giới thiệu.

Git là tuyệt vời, nhưng tôi tiếp tục quay trở lại Subversion cho kho lưu trữ nguồn cá nhân của tôi. Rốt cuộc, tôi không chia sẻ nó và Subversion chỉ dễ sử dụng hơn. Tôi sử dụng Git cho công việc cá nhân nếu tôi có một nhóm nhỏ vì tôi không phải lưu trữ toàn bộ kho lưu trữ của mình trên Internet. Đối với hầu hết các trang web thương mại, tôi vẫn thấy rằng Subversion hoạt động tốt nhất. Nhưng, có những trường hợp khi Git tỏa sáng.

Tôi không biết liệu hối lộ 'rượu và bữa tối' có còn được áp dụng hay không, nhưng đối với hầu hết các nhà quản lý khi họ quyết định tìm một sản phẩm họ sẽ đọc trong các ấn phẩm khác nhau (nhắm vào quản lý) và xem các tài liệu quảng cáo và tờ rơi quảng cáo về sản phẩm Đức tính.

Đoán xem, sản phẩm FOSS không có tính năng ở những nơi đó!

Vì vậy, gần như chắc chắn rằng hầu hết các quyết định mua quản lý đều được thúc đẩy bởi quảng cáo và tiếp thị. Họ có thể thực hiện đánh giá, nhưng một số sản phẩm như vậy.

Lý do khác là do sự trưởng thành. Một số sản phẩm chúng tôi sử dụng ngày nay chỉ đủ ổn định gần đây để sử dụng kinh doanh nghiêm túc, một số không có tùy chọn hỗ trợ, một số không có hồ sơ theo dõi đã được chứng minh là giải pháp kinh doanh. Đây là những điều quan trọng cần xem xét (mặc dù là một tín đồ công nghệ, tôi sẽ vui vẻ đánh giá các giải pháp FOSS nếu rủi ro sử dụng chúng và khiến chúng thất bại là tối thiểu để duy trì hoạt động kinh doanh) và một số nhà quản lý cảnh giác không có chúng xung quanh. Họ có trách nhiệm với ông chủ của mình và sẽ cảm thấy thoải mái hơn nhiều nếu có một tổ chức hỗ trợ đằng sau sản phẩm - sau tất cả, bạn có một tổ chức cho doanh nghiệp của mình.

Cuối cùng, trong khi nhiều sản phẩm FOSS có hỗ trợ đằng sau chúng (nghĩ Collabnet hoặc Wandisco cho SVN), thì nó vẫn nhận được danh tiếng 'được tạo ra bởi các chuyên viên máy tính trong phòng ngủ sau của họ. Chúng ta đều biết rằng nói chung là b * * ** t và FOSS tốt nhất cạnh tranh cực kỳ tốt với các dịch vụ thương mại, nhưng người quản lý của tôi vẫn cần phải bị thuyết phục. có lẽ anh ta không nhận ra sự khác biệt giữa các sản phẩm FOSS chưa trưởng thành và trưởng thành; có lẽ anh không quan tâm.

Dù sao, Perforce là một SCM tốt, không có lý do gì để không chọn nó. Tôi có thể nói tương tự cho các SCM khác, nhưng một lần nữa, tôi chỉ có thể nói những điều không hay về một số người khác, và vẫn gặp ác mộng khi nói đến một vài sản phẩm nhất định.

Bởi vì các công cụ như Perforce có nhân viên bán rượu và dùng bữa cho những người phụ trách mua hàng, trong khi Git thì không. Tất nhiên, đó chỉ là khía cạnh hoài nghi trong tôi khi nói, nhưng đó là một sự hoài nghi được đưa ra bằng cách nhìn thấy quá trình gần gũi.

Chỉ cần làm cho nó hoàn toàn rõ ràng: Tôi không có nghĩa là mỗi khi bạn thấy CIO của bạn vấp ngã say sưa dưới hành lang, hãy chờ đợi để sử dụng một hệ thống phiên bản mới vào quý tới. Chỉ là có một sự mất kết nối trong nhiều tổ chức giữa việc sử dụng và mua lại. Tất nhiên, có những lý do khác mà các công ty sử dụng Perforce: ví dụ, họ có thể đã đầu tư rất nhiều vào việc thực hiện nó trong quy trình làm việc của họ. Nhưng nói chung --- và câu hỏi này rất chung chung --- không có lợi thế chức năng nào khi không sử dụng các công cụ FOSS.

Có lẽ cùng một lý do công ty của tôi từ chối sử dụng nhiều phần mềm nguồn mở (không phải tôi đồng ý):

Khi có sự cố xảy ra, họ muốn ai đó họ có thể gọi và hét vào.

Mặc dù tất cả các câu trả lời đều nói về các công ty lớn sử dụng P4 (và họ trả lời tại sao Google sử dụng P4), một trong những lý do chính khiến Google tiếp tục sử dụng Perforce là Perforce cho phép bạn kiểm tra một cây con của repo trong khi bạn không thể làm điều đó với Git. Với các repos nguồn lớn như Google đã tạo ra sự khác biệt lớn.

Và theo như tôi được nghe, Facebook sử dụng SVN và Git-SVN

Bởi vì SVN, tốt, SVN và Perforce (từ 4 năm trước khi so sánh các công cụ) làm một số điều tốt hơn SVN . (Chi nhánh là một trong số đó tôi nghĩ.)

Và GIT là một DVcs, như trong phân phối . Đối với các nhóm công ty, phần phân phối có thể là điều không quan tâm cũng không mong muốn.

Một lý do khác mà các công ty lớn có xu hướng mua các hệ thống kiểm soát phiên bản lớn, klunky, "doanh nghiệp":

Quản lý cấp trung đến cấp cao trong các bộ phận CNTT xem VCS là thứ mà mọi dự án đơn lẻ sử dụng hoặc bạn có thể thực thi nó sử dụng. Khi bạn đã thực thi việc sử dụng một VCS, vậy thì tại sao bạn cũng không đặt một "quy trình" nhỏ trong đó? Ý tôi là, bạn đã có cơ hội chỉ định một hệ thống "toàn doanh nghiệp", tại sao không đặt nó dưới sự kiểm soát trung tâm và thêm "khắc phục thảm họa" và một số "tính năng quy trình công việc" để bạn có thể nói "Chúng tôi là CMM Level StraightJquet tuân thủ! ". Một VCS là một mục tiêu quá dễ dàng để đặt các tính năng thực thi quy trình công việc, là những gì nó đi xuống.

Theo như sự lựa chọn của một số phần mềm ickky-poo (Serena Dimensions), người ta nói rằng một vài vòng Bikini Golf ở Bahamas với một vài nhân viên bán hàng 20 tuổi có thể thuyết phục được Giám đốc hoặc VP về bất cứ điều gì.

Các công ty lớn cần một mô hình tập trung của một số loại. Khi các nhà phát triển hoàn thành việc phát triển, nó sẽ được trao cho bộ phận hỗ trợ khách hàng. Bạn có thực sự muốn được hỗ trợ giày khi họ phải kết hợp với 50-200 repos nhà phát triển phân tán không? Và các bản dựng được thực hiện dựa trên repo trung tâm, các bản dựng phải luôn luôn, luôn luôn, luôn có thể truy nguyên và có thể tái tạo. Bạn học điều này lần đầu tiên khi bạn bị đưa ra tòa vì một số vi phạm bằng sáng chế ngớ ngẩn.

Git không hoạt động tốt trong mô hình này. Nếu bạn có một công ty nhỏ hơn hoặc một công ty có quyền truy cập VPN kém, đó là nơi nó thực sự tỏa sáng.

Một lý do khiến hầu hết các công ty lớn sử dụng Perforce có thể là có nhiều chuyên gia hơn trong bộ phận CNTT có nhiều kiến ​​thức về nó và có nhiều năm kinh nghiệm gặp vấn đề khi chụp liên quan đến nó.

Tôi cảm thấy rằng trong tương lai các công ty có thể bắt đầu rời khỏi Perforce và hướng tới GIT ... hầu hết các nhà phát triển mà tôi biết dường như thích điều đó !! Ngoài ra, hãy xem http://whygitisbetterthanx.com/#git-is-fast để biết thêm bằng chứng về lý do tại sao Perforce có thể không chiếm ưu thế trong những năm tới !!

Cách đây một thời gian, chúng tôi đã chuyển từ một bộ VCS (tôi biết chắc chắn rằng RCS, CVS, ClearCase, Perforce đã được sử dụng trước đây, cũng có thể có những cái khác) sang Perforce như một hệ thống duy nhất được sử dụng. Đó không phải là một dự án nhỏ: việc di chuyển mất hơn một năm. Nhóm (tôi không phải là một phần của nó) phụ trách đã đánh giá một số VCS, và ít nhất git và svn đã được xem xét cũng như những người đã sử dụng. Khi tôi nhớ báo cáo của họ, họ đã lọc ra các công cụ mà không có các tính năng cần thiết và sau đó xem xét:

• hiệu suất sử dụng điển hình, đặc biệt là cho các trang web từ xa

• yêu cầu tài nguyên

• tầm quan trọng của những thay đổi cần thiết trong thói quen làm việc

• hỗ trợ sẵn có và chi phí

và Perforce là một người chiến thắng khá rõ ràng nói chung. git đã tốt hơn một chút cho điểm đầu tiên, nhưng bất lợi cho những người khác.

Ngày xưa, cách đây không lâu (khi IDE được gọi là VI), các hệ thống (nguồn mở) miễn phí duy nhất là CVS, RCS và SCCS.

• Không ai trong số này thậm chí có thể đối phó tốt với một tập tin được đổi tên.
• Họ đã không ghi lại sự hợp nhất, vì vậy nếu hai chi nhánh đang tích cực hoạt động thì rất khó để hợp nhất cho đến khi công việc hoàn thành trên một chi nhánh.
• Họ đã không mở rộng quy mô tốt đến các cơ sở mã rất lớn
• Họ không cung cấp mức độ kiểm soát truy cập và xử lý thông tin mà các dự án lớn muốn.

Có rất nhiều hệ thống kiểm soát mã nguồn thương mại ngoài kia, hầu hết các hệ thống này được cung cấp bởi một nhà cung cấp máy duy nhất (IBM, DEC, HP, v.v.) và chỉ chạy trên phần cứng của họ.

Sau đó, một số công ty tuyên bố bán kiểm soát mã nguồn thương mại đa nền tảng bao gồm Perforce và ClearCase.

ClearCase được xây dựng trên RPC không hoạt động tốt trên các mạng diện rộng (chỉ có một mình internet) do có rất nhiều gói mạng nhỏ bị vấp vòng, cũng như IBM và hợp lý đã thấy ClearCase là một con bò tiền mặt và không bao giờ hiển thị nó tình yêu.

Vì vậy, hệ thống kiểm soát mã nguồn thương mại duy nhất của Old Cũ vẫn còn được sử dụng phổ biến là Perforce. Khi lực lượng được sử dụng và tích hợp vào các hệ thống xây dựng và hệ thống theo dõi lỗi, có rất ít lợi ích ngắn hạn để một công ty chuyển sang bất kỳ thứ gì khác.

Vì vậy, để tóm tắt, lực lượng đã có được chân trên cửa ra vào khi mà không có nhiều lựa chọn khác và họ vẫn chưa gây rối đủ để khiến mọi người tránh xa nó .