Mengapa perusahaan besar menggunakan Perforce? [Tutup]

Saya mendengar tentang beberapa perusahaan besar misalnya Google, Facebook menggunakan Perforce

Apakah ada alasan mengapa SVN / Git tidak dapat menggantikan Perforce?

Pembenarannya mungkin kurang relevan dari dulu, tapi Perforce cenderung berkinerja lebih baik di repositori besar daripada Subversion. Ini adalah salah satu alasan Microsoft memperoleh lisensi sumber untuk Perforce untuk membangun Source Depot; Repositori NT adalah monster, dan tidak banyak produk, komersial atau lainnya, yang bisa menanganinya.

Juga, setidaknya pada satu waktu, alat visual untuk Perforce jauh lebih baik daripada apa yang tersedia di luar kotak (sehingga untuk berbicara) dengan Subversion atau Git. Jika Anda menggunakan Meld, mungkin hal-hal itu kurang penting daripada sebelumnya, tetapi masih ada beberapa hal yang Perforce lakukan dengan sangat baik, termasuk visualisasi percabangan dan penggabungan yang, meskipun saya tidak memiliki memori terperinci karena sudah sekitar 3 tahun sejak saya terakhir menyentuh Perforce, tampak lebih canggih daripada, misalnya, pendekatan Github untuk itu.

Setelah menggunakan Perforce, Anda dapat memahami apa manfaatnya dalam praktiknya. Mereka telah lama menawarkan opsi server dua pengguna gratis, dan tergantung pada sistem manajemen kode sumber yang Anda miliki, Anda mungkin merasa sepadan dengan biaya peningkatan setelah tim Anda mengujinya untuk sementara waktu. Untuk toko yang lebih kecil, ini, ditambah efek jaringan dari pengembang yang telah menggunakannya dan menyukainya, itulah sebabnya Perforce akhirnya mendapatkan pengguna yang membayar. Mungkin tidak banyak yang menang dan makan CTO untuk menjual Perforce di perusahaan dengan tim pengembangan kecil, berbeda dengan komentar sinis Dmitri, tetapi digunakan di tempat-tempat seperti itu.

Sebagian besar proyek yang saya kerjakan di luar Microsoft dapat dilayani dengan baik oleh Git, Mercurial, atau Subversion, dan saya akan mengatakan sebagian besar perusahaan tempat saya bekerja menggunakan salah satu opsi itu. Tetapi ada sweet spot, biasanya kombinasi ukuran repositori, model percabangan dan penggabungan, dan pengalaman tim / sejarah yang mengarahkan orang untuk menggunakan alat komersial. Saya jarang melihat repositori besar Git, misalnya. Ini mungkin bukan karena keterbatasan intrinsik Git; Saya akui sepenuhnya ketidaktahuan tentang itu. Tetapi dalam beberapa proyek (seperti Windows NT) mungkin ada beberapa batasan praktis untuk solusi gratis.

Saya cukup mahir dengan svn, git, dan Perforce, baik sebagai pengguna dan pengaturan dan pemeliharaan server.

Untuk sebuah perusahaan, atau bahkan seorang pemrogram tunggal seperti saya, kendali sumber adalah biaya yang dikeluarkan untuk mendukung aktivitas menghasilkan uang nyata, yang mengembangkan dan menjual kode. Jadi ada beberapa faktor yang perlu dipertimbangkan:

• Seberapa cocok dengan model pengembangan Anda?
• Seberapa mudah pengembang untuk belajar dan menggunakan?
• Apakah operasi rutin untuk pengembang cepat?
• Apakah proses menggunakannya sebagai gangguan dari pekerjaan mereka yang sebenarnya, yaitu menulis kode?
• Seberapa mudah mengatur dan memelihara?
• Berapa biaya untuk membeli dan memelihara?
• Jika Anda butuh bantuan, seberapa mudah mendapatkannya?

Saya akan melewatkan tl: detail dr tentang pro dan kontra dari sistem individu. Cukuplah untuk mengatakan bahwa ketika saya kembali ke konsultasi penuh waktu tahun lalu, saya meninjau ketiganya untuk memutuskan mana yang akan membuat saya menghasilkan uang secepat mungkin dengan mengirimkan perangkat lunak berkualitas kepada klien saya, dan tanpa memerlukan banyak pembayaran. main-main. Ketika saya mengambil pertimbangan politis "FOSS baik dan non-FOSS jahat" dari persamaan, saya akhirnya meminta izin Perforce.

Dan itu sebabnya perusahaan besar memilih Perforce juga.

Inilah tl: detail dr dari komentar, ditambah sedikit lagi.

Mengatasi svn itu mudah: dibandingkan dengan Perforce, sangat lambat. Saya bekerja di perusahaan yang menanamkan Linux untuk ponsel, dan sumber lengkap kami mencapai 9 GB; mereka menggunakan Perforce. Setelah Anda memiliki kode, memperbarui sumber terbaru biasanya berlangsung beberapa detik di LAN, atau beberapa menit melalui koneksi VPN dari rumah saya. Dengan svn, itu akan menjadi menit dan jam masing-masing.

git vs Perforce lebih rumit. Banyak perusahaan merasa mereka memiliki alasan bisnis yang baik untuk menggunakan repositori terpusat dengan kontrol akses, dan untuk membuatnya mudah dilakukan di sana dan sulit untuk melakukan hal lain - dan Perforce cocok dengan model itu dengan sempurna. Namun, git secara positif mendorong orang untuk bekerja di cabang lokal, dan tidak ada cara untuk membuatnya bekerja secara berbeda. Pengembang dapat bekerja sepenuhnya di cabang lokal dan tidak pernah berkomitmen pada repo pusat - jadi jika perusahaan tidak ingin karyawannya bekerja seperti itu, Perforce adalah pilihan yang lebih baik.

Ada masalah lain dengan git untuk beberapa kebutuhan bisnis. Saya bekerja di perusahaan yang menggunakan git, dan saya tidak tahu berapa kali saya mendengar diskusi ini: "Saya berharap kami menggunakan [beberapa VCS lain], karena saya perlu melakukan ini dan saya tidak bisa dengan git . " "Tentu saja kamu bisa melakukannya dengan git." "Bagaimana?" "Yah, pertama kamu harus menulis skrip bash ..." "Sudahlah."

Dan kemudian ada waktu yang diperlukan untuk awalnya mengisi pohon sumber yang memiliki banyak sejarah. Dengan Perforce, karena riwayat disimpan di server, Anda hanya mendapatkan versi terbaru dari semua file, jadi sangat cepat - bahkan mengatur bahwa seluruh pohon 9 GB yang saya sebutkan hanya butuh beberapa jam melalui VPN. Dengan git, ini bisa memakan waktu antara waktu yang lama dan selamanya. Saya kadang-kadang harus mengkloning GTK + atau repo git server X, dan itu adalah istirahat makan siang yang panjang, atau mungkin waktu untuk tidur.

Sungguh, ini masalah alat yang tepat untuk pekerjaan itu. svn berfungsi dengan baik untuk sebagian besar upaya open source Apple, dan akan sangat buruk untuk peretasan kernel. git bekerja sangat baik untuk GTK +, tetapi sangat lambat untuk bekerja di dalam WebKit - pohon sumber dan sejarah terlalu besar (karena saya menemukan cara sulit bekerja dengan kode dari portal svn-to-git WebKit). Perforce bekerja dengan baik jika Anda memiliki pohon sumber raksasa dan membutuhkan kontrol terpusat. Masing-masing berfungsi dengan baik dalam konteks yang benar.

Terutama GIT, dan SVN sampai taraf tertentu tidak setua itu - jika Anda memerlukan kontrol versi yang solid pada pertengahan 90-an, Anda hampir harus pergi komersial karena SVN masih dalam masa pertumbuhan dan CVS adalah, well, CVS. Setelah Anda banyak diinvestasikan dalam suatu sistem, memindahkannya dapat menjadi suatu dampak.

Oh, dan orang-orang yang membuat keputusan ini mungkin tidak pernah berinteraksi dengan sistem kontrol versi tetapi dimenangkan dan dinyanyikan oleh staf penjualan yang disebutkan di atas.

Saya sudah menjadi programmer di industri game selama hampir 9 tahun sekarang, dan setiap proyek yang pernah saya kerjakan telah menggunakan Perforce. Saya menduga bahwa ada beberapa hal yang membuat Perforce tetap digunakan dalam industri tertentu.

• Orang-orang telah menggunakan Perforce untuk waktu yang lama, dan cukup nyaman dengannya, membuat mereka ragu untuk beralih ke solusi lain. Para pembuat keputusan mungkin juga ragu untuk menempatkan proyek 30 juta dolar mereka di tangan perangkat lunak yang belum pernah mereka gunakan sebelumnya.
• Banyak perusahaan / tim telah menambahkan dukungan Perforce ke alat internal mereka, yang mungkin memerlukan sejumlah besar pekerjaan untuk diperbarui untuk mendukung VCS lain.
• Walaupun pemrogram mungkin memiliki waktu yang mudah untuk beralih ke Git / Hg / SVN lain, ada banyak anggota yang kurang teknis dari tim pengembangan game, seperti artis, desainer, dan produsen. Membuat mereka nyaman dengan sistem baru mungkin membutuhkan banyak waktu, dan saya berani bertaruh mereka akan cukup tahan terhadap perubahan.

Mungkin, mungkin mereka suka Perforce karena Perforce lebih baik?

• Perforce cepat. Jauh lebih cepat daripada Subversion atau Git.
• Penggabungan Perforce lebih baik daripada Subversion atau Git. Git tidak benar-benar melakukan penggabungan dan pelacakan versi Subversion tidak begitu baik, setidaknya dalam 1,5.
• Perforce memiliki dukungan pelanggan yang sangat baik.
• Perforce menggabungkan revisi repositori Subversion dengan revisi file individual. Perforce memungkinkan Anda untuk melihat revisi repositori melalui daftar perubahan atau revisi file individual.
• Perforce melakukan pekerjaan yang jauh lebih baik dengan banyak daftar perubahan daripada Subversion. Daftar perubahan Subversion agak ketinggalan jaman dan saya tahu sedikit yang menggunakannya. Perforce sudah ada di dalam. Jika Anda memindahkan file yang diubah dari daftar perubahan default, itu tidak mendapatkan komitmen tidak sengaja.
• Perforce memungkinkan Anda menentukan tata letak direktori kerja Anda. Misalnya, jika Anda memiliki hierarki direktori kode sumber standar, tetapi beberapa pelanggan memiliki sumber kustom, Anda bisa overlay sumber kustom di atas pohon standar. Anda dapat dengan mudah melakukan checkout jarang dengan menetapkan hanya item yang ingin Anda checkout.

Oke, sebelum Anda berpikir saya seorang Perforce Fanboi, terakhir kali saya merekomendasikan Perforce ke sebuah perusahaan adalah lebih dari tujuh tahun yang lalu. Perforce biaya $ 800 per lisensi - yang murah dibandingkan dengan ClearCase, tapi jauh lebih mahal jika dibandingkan dengan Subversion. Saya kesulitan membenarkan Perforce atas Subversion.

Plus, sebagian besar pengembang digunakan untuk Subversion. Mereka tidak ingin belajar Perforce yang memiliki cara kerja yang berbeda dari Subversion. Di Perforce, Anda harus membuat klien dan Anda harus menandai file untuk diedit sebelum Anda dapat memodifikasinya. Anda tidak harus melakukan itu dengan Subversion.

Ada sedikit integrasi dengan Perforce over Subversion juga. Bagian dari itu adalah karena penggunaan klien . Itu hanya tidak bermain dengan baik dengan VisualStudio atau bahkan Hudson. Sebagian darinya adalah karena Perforce harus membuat integrasi klien.

Ada biaya untuk panggilan lisensi hak milik biaya administrasi. Bayangkan jika Anda dapat melisensikan perangkat lunak dengan harga $ 1,00 per pengguna. Heck, mari kita buat dua bit. Ribuan lisensi hanya dikenakan biaya $ 250.

Sekarang, Anda membutuhkan orang penuh waktu yang mengelola lisensi. Rata-rata pekerja teknis tinggal di sekitar perusahaan selama sekitar 2 tahun. Itu berarti 500 orang setiap tahun akan pergi dan 500 lainnya datang. Sepuluh orang setiap minggu harus memiliki lisensi yang diubah. Lalu, ada saatnya proyek mengambil dan Anda membutuhkan 250 lisensi lagi. Itu harus dipesan, dimasukkan, dan dipelihara. Itu bisa memakan waktu berminggu-minggu.

Itu sebabnya banyak perusahaan komersial pindah ke open source. Itu bukan biaya lisensi. Anda membayar pengembang $ 150.000 per tahun, apa lagi $ 800 untuk lisensi Perforce? Ini mengelola lisensi itu. Perforce tampak hebat jika dibandingkan dengan ClearCase: Lebih cepat, lebih mudah, lebih murah, lebih baik. Tapi, menentang Subversi? Perforce mungkin lebih cepat dan mungkin lebih baik, tetapi apakah $ 800 lebih baik? Apakah ini mengelola lisensi dengan lebih baik? Apakah tidak menggunakan alat yang diinginkan lebih baik?

Itu sebabnya Perforce mungkin mengalami masalah.

Git bukanlah alat semua-menjadi-semua. Ini berfungsi dengan baik dalam situasi di mana Anda tidak ingin kontrol terpusat atas siapa yang memiliki akses ke repositori. Tapi, itu bisa menyakitkan di banyak situasi. Cara saya mengatakannya begini:

1. Anda menjalankan proyek open source. Apakah Anda akan senang atau kesal jika satu juta orang memiliki salinan seluruh repositori Anda?
2. Anda menjalankan meja perdagangan keuangan yang menggunakan perangkat lunak berpemilik untuk mendapatkan keunggulan pada pesaing Anda. Apakah Anda akan senang atau kesal jika satu juta orang memiliki salinan seluruh repositori Anda?

Jika Anda melakukan build terpusat, Anda membutuhkan semua orang untuk menggunakan repositori tunggal. Apa keuntungan dari sistem terdistribusi dalam keadaan ini? Bahkan, hal itu dapat mendorong orang untuk bekerja di luar jalur . Pengembang mungkin hanya pergi dengan cara mereka sendiri dan tidak melakukan apa pun sampai menit terakhir. Kemudian, Anda menghabiskan dua hari panik mencoba untuk membuat semuanya berfungsi kembali.

Saya tidak menentang Git. Saya telah merekomendasikan Git dalam banyak kasus. Ini termasuk tim terdistribusi dengan koneksi yang buruk satu sama lain, atau tempat-tempat di mana Anda tidak ingin melacak semua orang yang memiliki akses ke repositori sumber.

Sebagai contoh, departemen ilmu komputer perguruan tinggi ingin membuat siswa mereka menggunakan kontrol sumber dan meletakkan kode mereka di sana untuk dilihat oleh para guru. Ide yang hebat. Terlalu banyak anak meninggalkan perguruan tinggi tanpa memahami prosedur pembangunan dan pengembangan standar. Saya merekomendasikan Git.

Dengan menggunakan Git, administrator repositori hanya perlu menerima komit dari sesama profesor mereka. Mereka tidak perlu khawatir tentang siswa secara individu. Para profesor dapat mengizinkan siswa untuk berkomitmen pada versi repositori mereka. Siswa dapat bekerja dalam kelompok, dan setiap kelompok dapat membagikan versi repositori mereka.

Jika kampus menggunakan Subversion, seseorang harus mengetahui semua siswa dan memberikan mereka semua akses ke repositori pusat. Mereka harus mengatur siapa yang dapat memeriksa apa dan di mana. Jika seorang profesor menugaskan proyek kelompok, itu harus diatur dan dikelola. Anda akan membutuhkan orang penuh waktu hanya untuk mengelolanya.

Ini bukan pertandingan sepak bola di mana satu tim lebih baik dari yang lain. Alat bekerja dengan cara yang berbeda dan masing-masing memiliki kelebihan dan kekurangan. Perforce adalah alat yang hebat. Sayangnya, keadaan telah berkembang yang membuatnya sulit untuk direkomendasikan.

Git hebat, tetapi saya terus kembali ke Subversion untuk repositori sumber pribadi saya. Lagi pula, saya tidak membagikannya, dan Subversion lebih mudah digunakan. Saya menggunakan Git untuk pekerjaan pribadi jika saya memiliki tim kecil karena saya tidak perlu menyimpan repositori saya secara penuh di Internet. Untuk sebagian besar situs komersial, saya masih menemukan bahwa Subversion berfungsi paling baik. Tapi, ada beberapa kondisi ketika Git bersinar.

Saya tidak tahu apakah penyuapan 'anggur dan makan malam' masih berlaku, tetapi bagi sebagian besar manajer ketika mereka memutuskan untuk menemukan produk, mereka akan membaca di berbagai publikasi (ditargetkan pada manajemen) dan melihat brosur dan pamflet yang memuji produk tersebut. kebajikan.

Coba tebak, produk FOSS tidak tampil di tempat-tempat itu!

Jadi, hampir dapat dipastikan bahwa sebagian besar keputusan pembelian manajemen didorong oleh iklan dan pemasaran. Mereka dapat melakukan evaluasi, tetapi dari beberapa produk tersebut.

Alasan lainnya adalah karena jatuh tempo. Beberapa produk yang kami gunakan saat ini hanya cukup stabil untuk penggunaan bisnis yang serius, beberapa tidak memiliki opsi dukungan, beberapa tidak memiliki rekam jejak yang terbukti sebagai solusi bisnis. Ini adalah hal-hal penting yang perlu dipertimbangkan (meskipun sebagai teknisi saya akan dengan senang hati mengevaluasi solusi FOSS jika risiko menggunakannya dan kegagalan mereka minimal untuk menjaga agar bisnis tetap berjalan) dan beberapa manajer benar-benar waspada untuk tidak membawa mereka ke mana-mana. Mereka bertanggung jawab kepada atasan mereka dan akan merasa jauh lebih nyaman jika ada organisasi pendukung di belakang produk - Anda memiliki satu untuk bisnis Anda.

Terakhir, sementara banyak produk FOSS memiliki dukungan di belakang mereka (pikirkan Collabnet atau Wandisco untuk SVN), masih mendapatkan reputasi 'dibuat oleh Geeks di kamar tidur belakang mereka'. Kita semua tahu itu umumnya b * * ** t dan FOSS terbaik bersaing sangat baik dengan penawaran komersial, tetapi manajer saya masih perlu diyakinkan. mungkin dia tidak menyadari perbedaan antara produk FOSS yang belum matang dan yang sudah matang; mungkin dia tidak peduli.

Bagaimanapun, Perforce adalah SCM yang baik, tidak ada alasan untuk tidak memilihnya. Saya bisa mengatakan hal yang sama untuk SCM lain, tetapi di sana lagi, saya hanya bisa mengatakan hal-hal buruk tentang beberapa yang lain, dan masih memiliki mimpi buruk ketika datang ke beberapa produk tertentu.

Karena alat seperti Perforce memiliki salesman untuk anggur dan makan orang yang bertanggung jawab untuk membeli, sementara Git tidak. Tentu saja, itu hanya sisi sinis dari saya yang berbicara, tetapi ini adalah sinisme yang terjadi dengan melihat prosesnya dari dekat.

Hanya untuk membuatnya sangat jelas: Saya tidak bermaksud bahwa setiap kali Anda melihat CIO Anda tersandung mabuk di koridor, berharap untuk menggunakan sistem versi baru kuartal berikutnya. Hanya saja, ada pemutusan di banyak organisasi antara penggunaan dan akuisisi. Tentu saja ada alasan lain mengapa perusahaan menggunakan Perforce: misalnya, mereka mungkin telah banyak berinvestasi dalam implementasinya dalam alur kerja mereka. Tetapi umumnya --- dan pertanyaan ini sangat umum --- tidak ada keuntungan fungsional untuk tidak menggunakan alat FOSS.

Mungkin alasan yang sama perusahaan saya menolak untuk menggunakan banyak perangkat lunak open source (bukan karena saya setuju):

Ketika ada yang tidak beres, mereka menginginkan seseorang yang bisa mereka panggil dan berteriak.

Sementara semua jawaban berbicara tentang perusahaan besar yang menggunakan P4 (dan mereka menjawab mengapa Google menggunakan P4), salah satu alasan utama Google terus menggunakan Perforce adalah karena Perforce memungkinkan Anda untuk checkout subtree dari repo sedangkan Anda tidak dapat melakukannya dengan Git. Dengan repo sumber besar seperti Google yang membuat perbedaan besar.

Dan sejauh yang saya dengar, Facebook menggunakan SVN dan Git-SVN

Karena SVN adalah, well, SVN, dan Perforce (sejak 4 tahun yang lalu ketika membandingkan alat) melakukan beberapa hal lebih baik daripada SVN . (Percabangan adalah salah satu di antara mereka yang saya kira.)

Dan GIT adalah DVD, seperti yang didistribusikan . Untuk tim perusahaan, bagian yang didistribusikan mungkin merupakan sesuatu yang tidak dipedulikan atau diinginkan.

Alasan lain mengapa perusahaan besar cenderung membeli sistem kontrol versi "perusahaan" yang besar, klunky:

Manajemen menengah hingga atas di departemen TI melihat VCS sebagai sesuatu yang digunakan oleh setiap proyek, atau Anda dapat menegakkan penggunaannya. Setelah Anda menegakkan penggunaan VCS, lalu mengapa tidak menaruh sedikit "proses" di sana, juga? Maksud saya, Anda memiliki kesempatan untuk menentukan sistem "perusahaan-lebar", mengapa tidak mendapatkannya di bawah kendali pusat, dan menambahkan "pemulihan bencana" dan beberapa "fitur alur kerja" sehingga Anda bisa mengatakan "Kami CMJ Level StraightJacket patuh! " VCS adalah target yang terlalu mudah untuk menempatkan fitur-fitur yang memberlakukan alur kerja, begitulah yang terjadi.

Sejauh pilihan beberapa perangkat lunak ickky-poo, kasar (Dimensi Serena), dikatakan bahwa beberapa putaran Bikini Golf di Bahama dengan beberapa 20-staf penjualan staf wanita dapat meyakinkan Direktur atau VP tentang apa saja.

Perusahaan besar membutuhkan model yang tersentralisasi. Setelah pengembang selesai berkembang, itu diserahkan ke dukungan pelanggan. Apakah Anda benar-benar ingin berada di sepatu pendukung ketika mereka harus menyisir 50-200 repo pengembang terdistribusi? Dan membangun dilakukan berdasarkan repo pusat, membangun harus selalu, selalu, dapat dilacak, dan direproduksi. Anda mempelajari ini saat pertama kali Anda dibawa ke pengadilan atas beberapa pelanggaran paten konyol.

Git tidak bekerja dengan baik dalam model ini. Jika Anda memiliki perusahaan yang lebih kecil, atau perusahaan dengan akses VPN yang buruk, di situlah ia benar-benar bersinar.

Salah satu alasan sebagian besar perusahaan besar menggunakan Perforce mungkin adalah karena ada lebih banyak profesional di departemen TI yang memiliki banyak pengetahuan tentang hal itu dan memiliki pengalaman bertahun-tahun dalam masalah pemecahan masalah yang terkait dengannya.

Saya merasa bahwa di masa depan perusahaan mungkin mulai bergerak menjauh dari Perforce dan lebih ke arah GIT ... sebagian besar pengembang yang saya tahu sepertinya lebih menyukainya !! Lihat juga http://whygitisbetterthanx.com/#git-is-fast untuk bukti lebih lanjut tentang mengapa Perforce mungkin tidak dominan di tahun-tahun mendatang !!

Beberapa waktu yang lalu, kami beralih dari satu set VCS (saya tahu pasti bahwa RCS, CVS, ClearCase, Perforce telah digunakan sebelumnya, mungkin ada yang lain juga) ke Perforce sebagai sistem unik yang digunakan. Itu bukan proyek kecil: migrasi memakan waktu lebih dari satu tahun. Tim (saya bukan bagian dari itu) yang bertugas mengevaluasi beberapa VCS, dan setidaknya git dan svn dipertimbangkan serta yang sudah digunakan. Saya ingat laporan mereka, mereka memfilter alat tanpa fitur yang dibutuhkan dan kemudian mempertimbangkan:

• kinerja pada penggunaan umum, terutama untuk situs jarak jauh

• persyaratan sumber daya

• pentingnya perubahan yang dibutuhkan dalam kebiasaan kerja

• mendukung ketersediaan dan biaya

dan Perforce secara keseluruhan merupakan pemenang yang cukup jelas. git sedikit lebih baik untuk poin pertama, tetapi merugikan bagi yang lain.

Sekali waktu, belum lama (ketika IDE disebut VI), satu-satunya sistem (sumber terbuka) gratis adalah CVS, RCS dan SCCS.

• Tak satu pun dari ini bahkan dapat mengatasi dengan baik file diubah namanya.
• Mereka tidak mencatat penggabungan, jadi jika dua cabang aktif sedang bekerja, sangat sulit untuk menggabungkan sampai pekerjaan selesai pada satu cabang.
• Mereka tidak skala dengan baik ke basis kode yang sangat besar
• Mereka tidak memberikan tingkat kontrol akses dan memproses informan yang diinginkan oleh proyek besar.

Ada banyak sistem kontrol kode sumber komersial di luar sana, sebagian besar disediakan oleh vendor mesin tunggal (IBM, DEC, HP, dll) dan hanya berjalan pada perangkat keras mereka.

Kemudian beberapa perusahaan menyatakan untuk menjual kontrol kode sumber komersial lintas-platform termasuk Perforce dan ClearCase.

ClearCase dibangun di atas RPC yang tidak berfungsi dengan baik pada jaringan area luas (belum sendirian di internet) karena banyak paket jaringan kecil yang “bolak-balik”, juga IBM dan rasional melihat ClearCase sebagai “cash cow” dan tidak pernah menunjukkan banyak hal. cinta.

Jadi satu-satunya sistem kontrol kode sumber komersial "lama" yang masih umum digunakan adalah Perforce. Setelah terpaksa digunakan dan diintegrasikan ke dalam sistem build dan sistem pelacakan bug, hanya ada sedikit manfaat jangka pendek bagi perusahaan untuk pindah ke hal lain.

Jadi singkatnya, terpaksa mengambil "kaki di pintu" ketika tidak ada banyak pilihan lain, dan mereka belum cukup berantakan untuk membuat orang menjauh darinya .