Mengapa perusahaan besar menggunakan Perforce? [Tutup]


113

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

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


34
Saya mendengar Google menggunakan folder bernama timestamp pada drive yang dibagikan! ;)
FrustratedWithFormsDesigner

10
Hanya drive yang dibagikan menggunakan MapReduce, jadi mereka keren
Paul Stovell

4
Masalah besar akan menjadi dukungan. Ketika Anda membeli Perforce Anda membeli dukungan dari pengembang sistem, sesuatu yang mungkin tidak Anda dapatkan dari Git.
ChrisF

12
@Anto: Siapa yang peduli dengan apa yang dikatakan Linus? Hanya karena Anda seorang pengembang kernel yang brilian tidak berarti Anda tahu segalanya tentang semua hal di mana pun.
Billy ONeal

5
Baru saja datang dari Konferensi Pengguna Perforce 2 minggu lalu, saya dapat memberi tahu Anda Google menggunakan perforce. Mereka mendapatkan lebih dari 10.000 kiriman sehari ke 1 server mereka.
aflat

Jawaban:


83

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.


3
Terima kasih telah memberikan jawaban yang masuk akal selain teori "anggur dan makan malam" yang sinis. Ini mungkin benar untuk banyak perusahaan, tetapi ada yang beberapa alasan legit yang perusahaan pergi dengan terpaksa (atau menulis ulang: P). Saya tidak bisa membayangkan mencoba menangani sumber NT di SVN. Memang benar bahwa SVN dan Git sedang mengejar ketinggalan, dan mungkin untuk proyek besar baru, salah satunya adalah keputusan yang tepat. Tetapi pikirkan biaya yang terkait dengan pemindahan proyek langsung sebesar Windows (semua versi) dari satu sistem kontrol sumber ke yang lain. Itu tidak sepadan dengan biaya, terutama ketika sistem kontrol sumber saat ini bekerja.
Greg Jackson

1
Sebenarnya, mereka memang berpindah dari SLM (alat internal) ke Source Depot (garpu Perforce), jadi itu mungkin sepadan dengan biaya untuk seseorang dalam kasus itu. Tapi ya, itu tidak sepadan dengan biaya kecuali ada manfaat yang cukup besar.
JasonTrue

1
mendiskusikan.fogcreek.com/joelonsoftware/… memiliki sebagian riwayat ini dari sebagian besar sumber orang luar. (Saya sudah menjadi orang luar sejak 2004, FWIW).
JasonTrue

3
Saya tidak yakin dengan situasi repo besar. Saya mengelola satu, itu repo 12Gb (yaitu direktori server terkompresi adalah 12Gb) dan memiliki 320.000 revisi di dalamnya. Cukup cepat. Peluangnya adalah Microsoft menggunakan Perforce karena SVN tidak ada pada tahun 1999. maillist.perforce.com/pipermail/perforce-user/2001-August/… dan subversion.apache.org/docs/release-notes/release-history.html
gbjbaanb

8
@ gbjbaanb, itu bukan repositori besar ... hari ini itu dianggap sebagai yang berukuran sedang. ;) Lihat misalnya research.google.com/pubs/archive/34459.pdf
Alex Feinman

65

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.


2
Apakah masalah bahwa perusahaan besar memasukkan kode mereka ke dalam satu tempat penyimpanan? Bagaimana dengan menempatkan setiap 'modul' atau 'aplikasi' ke dalam repositori Git yang terpisah, sehingga ukuran repositori ini dapat dikelola? Masing-masing repositori ini kemudian akan mengimpor fungsionalitas yang diperlukan menggunakan fitur submodule Git. Dengan cara ini, pengelola repositori akan sesekali mengirimkan dokumen pullmereka untuk mendapatkan pembaruan atau fitur baru, dan hanya pada saat itu pengguna repositori tersebut akan membutuhkan pembaruan yang lebih besar daripada kode repositori itu sendiri.
Carl G

@Carl G: Jika Anda membaca semua jawaban di sini, Anda akan menemukan banyak alasan orang memilih Perforce daripada git yang tidak ada hubungannya dengan kemampuan git di sekitar repositori atau submodula.
Bob Murphy

Saya sedang mencoba untuk mengatasi "waktu yang diperlukan untuk awalnya mengisi pohon sumber itu", tetapi sebenarnya saya dapat melihat bahwa masalah submodule yang saya sebutkan tidak relevan karena submodula berisi semua sejarah repositori itu juga. Saya kira satu-satunya cara untuk mengurangi sejarah adalah dengan menggunakan binari dependensi.
Carl G

Nah, dengan git Anda dapat melakukan klon dangkal, dan hanya mendapatkan sedikit sejarah, atau mungkin hanya file terbaru (git clone --depth 1). Ini juga berfungsi untuk sub-modul git.
Sahil Singh

38

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.


4
+1. Kami beralih ke git relatif baru-baru ini, dan harus menjalankan terpaksa untuk waktu yang agak lama - hanya karena semuanya lebih rendah.
9000

11
Meskipun IMO Perforce menghabiskan banyak waktu saya. Kami masih menggunakannya di tempat kerja karena kami telah menginvestasikan waktu dalam mengembangkan alat khusus yang berinteraksi dengannya. Untuk beralih, kita harus membangun kembali alat-alat itu.
m4tt1mus

2
Perforce dan pengembang yang bodoh membuat saya benci memeriksa kode. Saya lebih suka menulis kode dengan krayon dan kompilasi itu .
Jim Schubert

Saya pikir Anda harus melihat memaksa sebelum berkomentar.
Toby Allen

30

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.

19
Saya pikir pengembang "lama" (+10 tahun) mungkin tahan terhadap perubahan seperti orang "non-teknis".
Wayne Werner

3
Memberi +1 pada ini, khusus untuk industri ini. Pemrogram video game cenderung memiliki begitu banyak hal, sehingga mengubah infrastruktur tempat mereka bekerja adalah suatu hal yang menakutkan. "Jika tidak rusak ..." adalah mantra, dan sering mencegah industri untuk beralih dari solusi yang lebih lama, bahkan jika mereka mungkin lebih cocok.
Chris Subagio

2
@Wayne - komentar yang sangat kuno. Saya berusia lebih dari enam puluh tahun dan saya adalah pendukung utama untuk perubahan dan inovasi di perantara saya ke situs besar. James Gosling berusia 46 ketika ia mulai menulis JVM pertama. Ken Thomson berusia 49 ketika ia datang dengan skema pengkodean UTF-8 dan 63 ketika ia mulai bekerja pada bahasa GO.
James Anderson

1
@ JamesAnderson Saya pikir Anda mungkin tepat di sana. Dan jika organisasi Anda tidak memiliki budaya perbaikan maka Anda akan melihat efek Laut Mati ikut bermain. Saya bertanya-tanya apakah mungkin untuk mengubah sistem secara keseluruhan, atau jika kita hanya bisa bermain-main dengan bagian kecil kita itu.
Wayne Werner

2
@ MikeO'Connor Anda juga lupa mengatakan bahwa game menggunakan banyak aset biner. Mampu mengunci secara eksklusif aset biner adalah nilai tambah BESAR.
CodingMadeEasy

22

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.


40
Tunggu apa? Anda kehilangan saya di sini, "Penggabungan paksa lebih baik daripada Subversi atau Git. Git benar-benar tidak benar-benar melakukan penggabungan [...]". Bisakah Anda jelaskan itu?
Sverre Rabbelier

1
Sebenarnya saya menemukan Git cukup bagus untuk penggabungan, lebih menyenangkan daripada alat scm sekolah lama, tetapi ketika di svn saya rindu bisa memasukkan hal-hal ke daftar perubahan "jangan cek" seperti yang sering saya lakukan dengan Perforce. (Saya sudah mencoba melakukannya di SVN, tetapi masih berakhir secara tidak sengaja memeriksa hal-hal karena perubahan svn dan p4 berperilaku berbeda).
JasonTrue

12
@SverreRabbelier 3 tahun kemudian, dan masih ada orang yang menunggu jawaban untuk pertanyaan Anda.
Navin

1
"karena Perforce lebih baik" ... "Ini bukan pertandingan sepak bola di mana satu tim lebih baik dari yang lain". ...
RJFalconer

4
memaksa cepat. jauh lebih cepat daripada svn atau git. --- benchmark, atau itu tidak terjadi ...; p
sjas

14

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.


Ini adalah argumen yang lebih menarik satu dekade yang lalu, tetapi banyak produk FOSS sangat mainstream saat ini; termasuk SVN, yang digunakan di beberapa perusahaan besar.
Jeremy

Saya tidak peduli bahwa FOSS memiliki hal yang tepat untuk bersaing - saya peduli bahwa manajer saya berpikir mereka tidak. Selain itu, beberapa bisnis besar bergerak lambat sehingga mereka masih bisa sampai di sana, beberapa dari mereka perlu beberapa tahun untuk mempertimbangkan mengevaluasi produk FOSS.
gbjbaanb

gbjbaanb Anda salah paham. Saya tidak berpikir faktor-faktor yang Anda gambarkan hampir sama relevannya pada tingkat manajemen apa pun sebagaimana satu dekade yang lalu. Meskipun itu mungkin situasi Anda , akan keliru untuk menyamaratakannya. FOSS adalah mainstream, yang berarti adalah diadopsi oleh sebagian besar perusahaan besar dan digunakan dalam sistem inti.
Jeremy

6
Saya pikir ini adalah poin utama: Alat FOSS tidak mengiklankan diri mereka sendiri, sungguh karena mereka tidak punya alasan untuk melakukannya. Bagian dari ini adalah brosur dan hal-hal yang Anda sebutkan, tetapi bahkan jika saya Google "sistem perbandingan SCM" atau "sistem kontrol versi perbandingan" satu-satunya hal yang saya temukan adalah yang dilakukan oleh Perforce. Tentu, saya harus mempertimbangkan sumbernya, tetapi saya tidak tahu alat FOSS melakukan upaya untuk mengiklankan diri mereka dan berbicara tentang mengapa mereka adalah yang terbaik. Saya tahu kita memandang rendah komersialisme, tetapi terkadang pemasaran dan periklanan sebenarnya membantu saya membuat pilihan yang tepat.
Peluang

1
Saya pikir ada dua alasan bagus untuk tidak memilih Perforce: 1. Bercabang sangat mahal, dan 2. Proses checkout-lalu-edit membuat pekerjaan offline sangat sulit untuk didamaikan.
kevin cline

14

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.


13
Ini mungkin terdengar sinis, tetapi pada dasarnya Anda telah memukul kuku di kepala. Di perusahaan saya sendiri, saya berjuang untuk mempromosikan solusi FOSS, karena eksekutif memiliki persepsi bahwa jika gratis itu tidak akan ada gunanya.
wolfgangsz

1
amen untuk itu, meskipun saya mungkin telah mengubahnya sedikit ketika mereka mengganti solusi SVN kami dengan 'perusahaan' yang harganya mahal, diperlukan konsultan, 2 kontraktor untuk mengadministrasikannya, dan setelah banyak meratap, kertakan gigi, operasi kereta dan kematian produktivitas kita ... dibuang dan diganti dengan solusi SVN lama kita.
gbjbaanb

7
Google tidak benar-benar dikenal karena budaya semacam ini.
Jeremy

11
@ Peluang: Hal apa yang Anda hubungi untuk dukungan teknis? Saya telah menggunakan CVS, Subversion, dan Mercurial, dan saya tidak pernah menemukan diri saya berharap ada seseorang yang bisa saya hubungi. Jika saya memiliki masalah, saya google, atau saya memposting pertanyaan, dan itu diselesaikan, biasanya dalam beberapa menit. Saya menyarankan bahwa alat kontrol sumber yang memerlukan dukungan dari pengembang sistem memiliki masalah serius.
Tom Anderson

2
@TobyAllen: bukan untuk sekitar enam tahun (perhatikan tanggal pertanyaan) Tapi hari ini sepertinya bahkan Perforce ingin menggunakan sesuatu selain Perforce: perforce.com/git
Dmitri

12

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.


2
Saya setuju: ini adalah alasan besar bagi banyak departemen TI, tetapi tampaknya belum matang. "Itu bukan kesalahan kita, ini KESALAHAN MEREKA". Memilih produk yang inferior hanya karena potensi menunjuk dengan jari "satu leher untuk diperas" sepertinya merupakan keputusan yang kekanak-kanakan. Bukannya itu tidak sering dibuat, hanya saja sepertinya kekanak-kanakan.
Bruce Ediger

Jawaban Anda tidak merujuk pada dukungan teknis Perforce. Sayang sekali, karena jika Anda tahu betapa baiknya itu, jawaban Anda mungkin tidak muncul. Dukungan teknis Perforce bintang dan berkomitmen, dan mereka mendapatkan hal-hal yang diperbaiki CEPAT.
Br.Bill

9

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


1
Tentu saja, subrepos mendorong dan mempermudah penggunaan kembali kode. Inilah mengapa saya memilih Perforce ketika saya memiliki suara dalam masalah ini. Masalah besar! Mudah mencampur dan mencocokkan kode dari repo yang berbeda (subrepo hg), melacak siapa yang menggunakan subrepo tertentu, kemampuan untuk dengan mudah melacak checkin, cabang dan penggabungan ke semua repo. Sementara itu membuatnya sangat sederhana untuk pengembang akhir dengan spec klien garis tunggal dan menyimpan detail dalam spesifikasi cabang untuk pengguna super. Saat ini, saya terpaksa menggunakan Mercurial pada proyek besar dan berurusan dengan repo-repo dengan hg menghabiskan banyak uang dalam produktivitas yang hilang.
stephenmm

8

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.


5
Anda dapat menggunakan Git baik-baik saja dengan alur kerja yang berbeda, sehingga didistribusikan bukan masalah ... kecuali tim perusahaan tidak mengerti. whygitisbetterthanx.com/#any-workflow
M. Dudley

2
Saya tidak akan mengatakan bahwa Perforce melakukan percabangan dengan baik ... menciptakan cabang Perforce menghasilkan salinan sibuk dari semua yang bercabang. Cabang SVN dengan salinan malas, sehingga cabangnya jauh lebih cepat.
kevin cline

1
@Jason - percabangan pada subversi terjadi lebih cepat daripada yang saya bisa ketik: "svn cp ...; svn switch ..." Pada penciptaan cabang memaksa sangat rumit; buat spec cabang, buat ruang kerja, integrasi, komit. Heck, dengan terpaksa semua seperti itu. Tanpa percabangan yang cepat dan mudah, saya menganggap RCS pada dasarnya tidak dapat digunakan. Dilihat oleh lalu lintas bersih dan kecepatan peningkatan, sepertinya Perforce adalah produk akhir masa pakai.
kevin cline

1
@ kevin, saya tidak yakin bagaimana Anda melakukan percabangan, tapi saya hanya melakukan bagian integrasikan. Saya tidak pernah membuat spesifikasi cabang dan saya tidak pernah harus membuat ruang kerja ke cabang (walaupun saya mungkin harus mengubah pemetaan tampilan saya jika saya memutuskan untuk mengecualikan direktori dalam tampilan saya). Yang sedang berkata, saya belum melakukan apa pun dengan svn jadi saya tidak bisa mengomentari aspek itu.
Peluang

1
@ kevin: Anda tahu, apakah sesuatu "bekerja lebih baik" belum tentu merupakan fungsi dari jumlah perintah CLI yang diperlukan untuk melakukannya. Hanya komentar dari seseorang yang tidak mahir dalam SVN atau Perforce.
Martin Ba

6

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.


tidak ada komentar, tetapi saya ingin tahu mana dari kontraktor atau manajer kami yang bisa bermain golf bikini!
gbjbaanb

5
Saya akui saja, Bikini Golf mungkin juga akan bekerja pada saya.
jhocking

5

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.


2
Ini semua tentang mendefinisikan alur kerja, terpusat atau terdesentralisasi tidak masalah. Pekerjaan dukungan tidak mudah ketika mencoba menyisir 200 cabang di pusat repo. Pada umumnya, perusahaan memilih solusi terpusat karena itulah yang membuat mereka nyaman. Tidak ada keuntungan yang berarti dibandingkan DVCS yang digunakan dengan repositori bersama yang terpusat.
wadesworld

4

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 !!


4

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.


3

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 .

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.