it-swarm.asia

Neden büyük şirketler Perforce kullanıyor?

Bazı büyük şirketleri duydum; Google, Facebook Perforce kullanıyor

SVN/Git'ün Perforce'ın yerini alamamasının bir nedeni var mı?

119
user34401

Gerekçe belki de eskisinden daha az önemlidir, ancak Perforce büyük havuzlarda Subversion'dan daha iyi performans gösterir. Bu, Microsoft'un Kaynak Deposu oluşturmak için Perforce'a kaynak lisansı edinmesinin nedenlerinden biridir; NT'nin deposu bir canavardır ve ticari ya da başka türlü pek çok ürün bunu başaramaz.

Ayrıca, en azından bir kerede, Performce için görsel araçlar Subversion veya Git ile kutudan çıkanlardan (sözde) çok daha iyiydi. Meld kullanıyorsanız belki de bu şeyler bir zamanlar olduğundan daha az önemli, ancak performansın çok güzel yaptığı, dallanma ve birleştirme görselleştirmeleri de dahil olmak üzere birkaç şey var. Perforce'a en son dokunduğumdan yaklaşık 3 yıl sonra, örneğin Github'un buna yaklaşmasından daha sofistike görünüyordu.

Perforce kullandıktan sonra, pratikte avantajlarının ne olduğunu anlayabilirsiniz. Uzun zamandır ücretsiz iki kullanıcılı sunucu seçeneği sundular ve hangi kaynak kodu yönetim sistemlerine sahip olduğunuza bağlı olarak, ekibiniz bir süre test ettikten sonra yükseltme maliyetine değebilir. Daha küçük mağazalar için, bu artı onu kullanan ve seven geliştiricilerin ağ efektleri, Perforce'nin ödeme yapan kullanıcılara ulaşmasının nedenidir. Dmitri'nin alaycı sözlerinin aksine, Performansı küçük geliştirme ekiplerine sahip şirketlerde satmak için muhtemelen çok fazla CTO'yu yemek ve yemek yok, ancak bu gibi yerlerde kullanılıyor.

Microsoft dışında çalıştığım projelerin çoğuna Git, Mercurial veya Subversion tarafından oldukça iyi hizmet verilebiliyor ve bu seçeneklerden birini kullanmak için çalıştığım şirketlerin çoğunun söyleyebilirim. Ancak tatlı bir nokta var, genellikle depo büyüklüğü, dallanma ve birleştirme modeli ve insanları ticari araçları kullanmaya yönlendiren ekip deneyimi/tarihinin bir kombinasyonu. Örneğin, büyük Git depolarını nadiren gördüm. Bunun nedeni Git'in herhangi bir yapısal sınırlaması olmayabilir; Bunu tam olarak bilmiyorum. Ancak bazı projelerde (Windows NT gibi) ücretsiz çözümlerin bazı pratik sınırları olabilir.

83
JasonTrue

Svn, git ve Perforce konusunda hem kullanıcı hem de sunucu kurma ve bakımını yapma konusunda oldukça yetkinim.

Bir şirket, hatta benim gibi yalnız bir programcı için kaynak kontrolü, kod geliştiren ve satan gerçek para kazanma etkinliğini desteklemek için yapılan bir maliyettir. Bu yüzden dikkate alınması gereken birkaç faktör var:

  • Geliştirme modelinize ne kadar uygundur?
  • Geliştiricilerin öğrenmesi ve kullanması ne kadar kolay?
  • Geliştiriciler için rutin işlemler hızlı mı?
  • Bunu kullanma süreci, kod yazmak için gerçek işlerinden uzaklaşıyor mu?
  • Kurulumu ve bakımı ne kadar kolaydır?
  • Satın almanın ve bakımının maliyeti nedir?
  • Yardıma ihtiyacınız varsa, bunu almak ne kadar kolay?

Bireysel sistemlerin artıları ve eksileri hakkında tl: dr detayını atlayacağım. Geçen yıl tam zamanlı danışmanlığa döndüğümde, üçünü de inceleyerek, müşterilerime kaliteli yazılım sunarak ve mümkün olan en hızlı şekilde en çok parayı kazanmama izin verecek şekilde karar verdim. ortalıkta dolanmak. "FOSS iyi ve FOSS olmayan şeytani" gibi politik düşünceyi denklemden çıkardığımda, Performans lisansı almak için yaralandım.

Bu yüzden büyük şirketler de Performance'ı seçiyor.


İşte tl: dr yorumlardan detaylar, artı biraz daha.

SVN'ye hitap etmek kolaydır: Perforce ile karşılaştırıldığında, köpek yavaştır. Cep telefonları için Linux yerleştiren bir şirkette çalıştım ve tüm kaynaklarımız 9 GB çalıştı; Perforce kullandılar. Kodu edindikten sonra, en son kaynakları güncellemek normalde LAN'da saniyeler veya evimdeki bir VPN bağlantısı üzerinden birkaç dakika sürdü. Svn ile, sırasıyla dakika ve saat olurdu.

git'e karşı Performans daha karmaşıktır. Birçok şirket, erişim kontrolü ile merkezi bir depo kullanmak ve orada iş yapmayı kolaylaştırmak ve başka bir şey yapmak zor hale getirmek için iyi iş nedenlerine sahip olduklarını düşünüyor ve Perforce bu modele mükemmel bir şekilde uyuyor. Ancak git, insanları yerel bir dalda çalışmaya teşvik eder ve farklı bir şekilde çalışmasını sağlamanın bir yolu yoktur. Bir geliştirici tamamen yerel bir şubede çalışabilir ve asla merkezi repoya bağlı kalmaz - bu nedenle bir şirket çalışanlarının bu şekilde çalışmasını istemiyorsa, Perforce daha iyi bir seçenektir.

Bazı iş ihtiyaçları için git ile ilgili başka sorunlar var. Git kullanan bir şirkette çalıştım ve bu tartışmayı kaç kez duyduğumu bilmiyorum: "Keşke [diğer VCS] 'yi kullansaydık, çünkü [bunu] yapmam gerekiyor ve git ile yapamam ." "Elbette bunu git ile yapabilirsiniz." "Nasıl?" "Peki, önce bash betiği yazmalısın ..." "Boş ver."

Ve sonra başlangıçta çok fazla geçmişi olan bir kaynak ağacı doldurmak için gereken zaman var. Perforce ile, tarih sunucuda tutulduğundan, tüm dosyaların en son sürümlerini alırsınız, bu yüzden gerçekten hızlı - bahsettiğim 9 GB ağacın tamamını kurmak bir VPN üzerinden sadece birkaç saat sürdü. Git ile, uzun bir süre ile sonsuzluk arasında bir yer alabilir. Bazen GTK + veya X sunucusu git depolarını klonlamak zorundayım ve bu uzun bir öğle yemeği molası, ya da belki de yatma zamanı.

Gerçekten, bu iş için doğru araç meselesi. svn, Apple'ın açık kaynak çabalarının çoğunda iyi çalışır ve çekirdek korsanlığı için korkunç olur. git, GTK + için harika çalışıyor, ancak WebKit içinde çalışmak için inanılmaz derecede yavaş - kaynak ağacı ve geçmişi çok büyük (WebKit'in svn-to-git portalından kodla çalışmanın zor yolunu öğrendim). Dev bir kaynak ağacınız varsa ve merkezi kontrole ihtiyacınız varsa, performans iyi çalışır. Her biri doğru bağlamda iyi çalışıyor.

65
Bob Murphy

Özellikle GIT ve bir dereceye kadar SVN o kadar eski değil - 90'ların ortasında sağlam sürüm kontrolüne ihtiyacınız varsa, SVN bebeklik döneminde olduğu ve CVS'nin CVS olduğu için neredeyse ticari hale gelmek zorundaydınız. Bir sisteme çok fazla yatırım yaptıktan sonra onu taşımak bir ayı olabilir.

Oh, ve bu kararları veren çocuklar muhtemelen sürüm kontrol sistemi ile asla etkileşime girmezler, ancak yukarıda bahsedilen satış personeli tarafından kazanılır ve dined.

38
Wyatt Barnett

Neredeyse 9 yıldır oyun endüstrisinde programcıyım ve üzerinde çalıştığım her proje Perforce kullandı. Şüpheliyim ki, söz konusu sektörde Perforce'i kullanımda tutan birkaç şey var.

  • İnsanlar uzun zamandır Perforce kullanıyorlar ve onunla oldukça rahatlar, bu da onları başka bir çözüme geçmekte tereddüt ediyorlar. Karar vericiler ayrıca 30 milyon dolarlık projelerini daha önce hiç kullanmadığı yazılımların eline geçirmekte tereddüt edebilirler.
  • Birçok şirket/ekip, şirket içi araçlarına Performans desteği ekledi; bu da başka bir VCS'yi desteklemek için güncellenmesi için önemli miktarda çalışma gerektirebilir.
  • Programcılar başka bir Git/Hg/SVN'ye geçmek için kolay bir zaman geçirebilirken, sanatçılar, tasarımcılar ve yapımcılar gibi bir oyun geliştirme ekibinin daha az teknik üyesi var. Yeni sistemle onları rahat ettirmek çok zaman alabilir ve değişime oldukça dirençli olduklarına bahse girmeye istekli olurum.
30
Mike O'Connor

Belki, belki Performans'ı severler çünkü Performans daha iyidir?

  • Performansı hızlı. Subversion veya Git'ten çok daha hızlı.
  • Performans birleştirmesi Subversion veya Git'ten daha iyidir. Git gerçekten birleştirme yapmıyor ve Subversion'ın sürüm takibi o kadar iyi değil, en azından 1.5.
  • Performansın mükemmel müşteri desteği vardır.
  • Performans, Subversion'un depo revizyon dosyasını tek tek dosya revizyonlarıyla birleştirir. Performans, listeleri değiştir veya tek tek dosya düzeltmeleri yoluyla depo revizyonlarını görüntülemenizi sağlar.
  • Performance, Subversion'a göre birden fazla değişiklik listesiyle çok daha iyi bir iş çıkarır. Subversion'un changelistleri bir şekilde sonradan düşünülen bir şey ve bunu kullanan azını biliyorum. Performans yerleşiktir. Değiştirilmiş bir dosyayı varsayılan değişiklik listesinden taşırsanız, yanlışlıkla işlenmez.
  • Performans, çalışma dizini düzeninizi belirlemenizi sağlar. Örneğin, standart bir kaynak kodu dizin ağacınız varsa, ancak bazı müşterilerin özel kaynağı varsa, özel kaynağı standart ağacın üzerine bindirebilirsiniz. Yalnızca ödeme yapmak istediğiniz öğeleri belirterek kolayca seyrek ödeme yapabilirsiniz.

Tamam, bir Perforce Fanboi olduğumu düşünmeden önce, Perforce'ı bir şirkete en son tavsiye ettiğim yedi yıl önce oldu. Performansın lisansı 800 $ 'dır - ki bu ClearCase'e kıyasla ucuzdur, ancak Subversion'a kıyasla çok pahalıdır. Yıkım Performansını haklı çıkarmakta zorlanıyorum.

Ayrıca, çoğu geliştirici Subversion'u kullanıyor. Subversion'dan farklı bir çalışma şekline sahip bir Performans öğrenmek istemiyorlar. Perforce'de, bir istemci oluşturmanız ve dosyaları değiştirmeden önce düzenlemek üzere işaretlemeniz gerekir. Subversion ile bunu yapmak zorunda değilsiniz.

Subversion Üzerinden Performans ile daha az entegrasyon vardır. Bunun bir kısmı istemci kullanımından kaynaklanmaktadır. VisualStudio ve hatta Hudson ile iyi oynamıyor. Bunun bir kısmı, Perforce'ın istemci entegrasyonlarını yaratması gerektiğidir.

Tescilli lisans için idari maliyeti aramanın bir maliyeti vardır. Bir yazılım parçasını kullanıcı başına 1,00 ABD Doları karşılığında lisanslayabileceğinizi düşünün. Heck, iki bit yapalım. Binlerce lisans size sadece 250 dolara mal olacak.

Şimdi, lisansı yöneten tam zamanlı bir kişiye ihtiyacınız var. Ortalama bir teknik işçi bir şirkette yaklaşık 2 yıl kalır. Yani her yıl 500 kişi ayrılacak ve 500 kişi daha gelecek. Her hafta on kişinin lisansının değişmesi gerekiyor. Ardından, projenin alındığı zamanlar vardır ve 250 lisansa daha ihtiyacınız vardır. Bunlar sipariş edilmeli, girilmeli ve bakımı yapılmalıdır. Bu haftalar alabilir.

Bu yüzden birçok ticari firma açık kaynak koduna geçti. Bu bir lisansın maliyeti değildir. Bir geliştiriciye yılda 150.000 dolar ödüyorsunuz, Performans lisansı için 800 dolar daha mı? Bu lisansı yönetiyor. ClearCase ile karşılaştırıldığında performans harika görünüyor: Daha hızlı, daha kolay, daha ucuz, daha iyi. Ama yıkıma karşı mı? Performans daha hızlı ve belki daha iyi olabilir, ancak 800 $ daha iyi mi? Lisansı daha iyi yönetiyor mu? İstenen aracı daha iyi kullanmıyor mu?

Bu yüzden Perforce problem yaşıyor olabilir.

Git, hepsi bir arada araç değildir. Kimin bir depoya erişimi olduğu konusunda merkezi kontrol istemediğiniz durumlarda harika çalışır. Ancak, birçok durumda bir ağrı olabilir. Benim koyma şeklim şu şekilde:

  1. Açık kaynaklı bir proje çalıştırıyorsunuz. Bir milyon kişinin tüm deponuzun bir kopyasını alması durumunda mutlu olur musunuz?
  2. Rakiplerinize avantaj sağlamak için özel yazılım kullanan bir finansal işlem masası çalıştırıyorsunuz. Bir milyon kişinin tüm deponuzun bir kopyasını alması durumunda mutlu olur musunuz?

Merkezi yapılar yapıyorsanız, yine de herkesin tek bir depo kullanması gerekir. Bu durumda dağıtılmış bir sistemin avantajı nedir? Aslında, insanları çalışmaya teşvik edebilir çevrimdışı. Geliştiriciler sadece kendi neşeli yollarına gidebilir ve son dakikaya kadar hiçbir şey taahhüt edemezler. Ardından, her şeyi yeniden çalıştırmaya çalışmak için iki çılgın gün geçiriyorsunuz.

Git'e karşı değilim. Git'i birçok durumda tavsiye ettim. Bunlar, birbirine zayıf bağlantıları olan dağıtılmış ekipleri veya kaynak havuzuna erişimi olan herkesi izlemek istemediğiniz yerleri içerir.

Örneğin, bir üniversite bilgisayar bilimleri bölümü, öğrencilerinin kaynak kontrolünü kullanmasını ve öğretmenlerin bakması için kodlarını oraya koymak istedi. İyi fikir. Çok fazla çocuk standart inşa ve geliştirme prosedürlerini anlamadan üniversiteden ayrılır. Git'i tavsiye ettim.

Git'i kullanarak, deponun yöneticisi sadece profesörlerinden taahhüt almak zorundadır. Bireysel öğrenciler için endişelenmeleri gerekmez. Profesörler öğrencilerin depo versiyonlarına bağlı kalmalarına izin verebilir. Öğrenciler gruplar halinde çalışabilir ve her grup depo sürümünü paylaşabilir.

Eğer kolej Subversion kullansaydı, birisinin tüm öğrencileri tanıması ve hepsinin merkezi depoya erişimini sağlaması gerekirdi. Kimin neyi ve nerede kontrol edebileceğini yönetmek zorunda kalacaklardı. Bir profesör bir grup projesi atarsa, bunun kurulması ve yönetilmesi gerekir. Bunu yönetmek için tam zamanlı bir kişiye ihtiyacınız olacak.

Bu, bir takımın diğerinden daha iyi olduğu bir futbol oyunu değil. Araçlar farklı şekillerde çalışır ve her birinin avantajları ve dezavantajları vardır. Performans harika bir araçtır. Ne yazık ki, önerilmesini zorlaştıran koşullar gelişti.

Git harika, ama kişisel kaynak havuzum için Subversion'a geri dönmeye devam ediyorum. Sonuçta, paylaşmıyorum ve Subversion'un kullanımı daha kolay. Küçük bir ekibim varsa Git'i kişisel işler için kullanıyorum çünkü depomu internette tam zamanlı tutmak zorunda değilim. Çoğu ticari site için, Subversion'un en iyi sonucu verdiğini görüyorum. Ancak Git'in parladığı durumlar vardır.

23
David W.

Perforce gibi araçların şarap satın almak ve satın almakla sorumlu insanları yemek için satıcıları var, Git ise yok. Tabii ki, bu sadece konuşmamın alaycı tarafı, ama süreci yakından görerek ortaya çıkan bir sinizm.

Sadece mükemmel bir şekilde açıklığa kavuşturmak için: Ben don't CIO'nuzun koridorda sarhoş bir şekilde tökezlediğini her gördüğünüzde, önümüzdeki çeyrekte yeni bir versiyonlama sistemi kullanmayı umuyorsunuz. Sadece birçok kuruluşta kullanım ve edinme arasında bir kopukluk olması. Tabii ki şirketlerin Perforce'yi kullanmasının başka nedenleri de var: örneğin, zaten iş akışlarına uygulanmasına büyük yatırım yapmış olabilirler. Ancak genel olarak --- ve bu soru çok geneldir --- FOSS araçlarını kullanmamanın işlevsel bir avantajı yoktur.

14
Dmitri

'Şarap ve yemek' rüşvetinin hala geçerli olup olmadığını bilmiyorum, ancak çoğu yönetici için bir ürün bulmaya karar verdiklerinde çeşitli yayınlarda (yönetime yönelik) okuyacaklar ve ürünü öten broşürlere ve broşürlere bakacaklar erdemler.

Bilin bakalım, FOSS ürünleri bu yerlerde bulunmuyor!

Yani, çoğu yönetim-satın alma kararının reklam ve pazarlama tarafından yönlendirildiği neredeyse veriliyor. Bu tür ürünlerin birçoğunu değerlendirebilirler.

Diğer neden ise olgunluktur. Bugün kullandığımız bazı ürünler son zamanlarda ciddi iş kullanımı için yeterince kararlıdır, bazılarının destek seçenekleri yoktur, bazılarının iş çözümleri olarak kanıtlanmış bir geçmişi yoktur. Bunlar göz önünde bulundurulması gereken önemli şeylerdir (ancak bir teknisyen olarak, FOSS çözümlerini kullanma ve başarısız olma riski işin devam etmesini sağlamak için minimum ise mutlu bir şekilde değerlendireceğim) ve bazı yöneticiler haklı olarak etrafta olmamaya dikkat ediyorlar. Patronlarından sorumludurlar ve ürünün arkasında bir destek organizasyonu varsa çok daha rahat hissedeceklerdir - sonuçta işiniz için bir tane var.

Son olarak, birçok FOSS ürününün arkasında destek olsa da (SVN için Collabnet veya Wandisco'yu düşünün), yine de 'arka yatak odasında geeks tarafından yapılmış' itibarını kazanıyor. Hepimiz bunun genellikle b * * ** t olduğunu biliyoruz ve en iyi FOSS, ticari tekliflerle inanılmaz derecede iyi rekabet ediyor, ancak yöneticimin hala ikna edilmesi gerekiyor. belki de olgunlaşmamış ve olgun FOSS ürünleri arasındaki farkı anlamıyor; belki umursamaz.

Her neyse, Perforce iyi bir SCM, onu seçmemek için bir neden yok. Aynı şeyi diğer SCM'ler için de söyleyebilirdim, ama yine de, başkaları hakkında sadece kötü şeyler söyleyebilirim ve belirli bir çift ürün söz konusu olduğunda hala kabuslar görüyorum.

14
gbjbaanb

Muhtemelen şirketimin açık kaynak kodlu bir çok yazılımı kullanmayı reddetmesinin nedeni de aynıdır (kabul etmiyorum):

Bir şeyler ters gittiğinde arayabilecekleri ve bağırabilecekleri birini isterler.

12
Michael

Tüm yanıtlar P4 kullanan büyük şirketler hakkında konuşurken (ve Google'ın neden P4 kullandığını yanıtlıyorsa), Google'ın Perforce'ı kullanmaya devam etmesinin ana nedenlerinden biri de Perforce'nin repo alt ağacını kontrol etmenize izin verirken, Git ile bunu yapamazsınız. Google gibi büyük kaynak depolarıyla büyük fark yarattı.

Duyduğum kadarıyla Facebook SVN ve Git-SVN kullanıyor

9
manojlds

Çünkü SVN, SVN ve Perforce (araçları karşılaştırırken 4 yıl öncesinden itibaren) bazı şeyleri SVN'den daha iyi yapar . (Dallanma bence bunlardan biri.)

Ve GIT dağıtılan bir Dvcs . Şirket ekipleri için, dağıtılan kısım ne umursamıyor ne de istediği bir şey olabilir.

8
Martin Ba

Büyük şirketlerin büyük, klunky, "kurumsal" sürüm kontrol sistemleri satın alma eğiliminde olmasının bir başka nedeni:

BT departmanlarındaki orta ila üst yönetim, VCS'yi her bir projenin kullandığı bir şey olarak görür veya kullanımını zorlayabilirsiniz. Bir VCS kullanımını zorladıktan sonra, oraya neden küçük bir "süreç" koymuyorsunuz? Demek istediğim, "kurumsal çapta" bir sistem belirleme fırsatınız var, neden merkezi kontrol altına almıyorsunuz ve "olağanüstü durum kurtarma" ve bazı "iş akışı özellikleri" ekleyebiliyorsunuz, böylece "Biz CMM Düzeyi StraightJacket'iz Uysal!". Bir VCS, iş akışını güçlendirici özellikler koymak için bir hedef olmaktan çok kolaydır.

Bazı ickky-poo, hileli yazılım (Serena Dimensions) seçimine gelince, Bahamalar'da birkaç 20 şeylik kadın satış görevlisi ile birkaç tur Bikini Golf'ün bir Direktörü veya Başkan Yardımcısı'nı hemen hemen her şeye ikna edebileceği söyleniyor.

6
Bruce Ediger

Büyük şirketlerin bir tür merkezi bir modele ihtiyaçları vardır. Geliştiriciler geliştirildikten sonra, müşteri desteğine teslim edilir. 50-200 dağıtılmış geliştirici deposuyla taramak zorunda kaldıklarında gerçekten destek ayakkabılarında olmak ister misiniz? Ve yapılar merkezi repoya göre yapılır, yapılar her zaman, her zaman, her zaman izlenebilir ve tekrarlanabilir olmalıdır. Bunu, aptalca patent ihlali nedeniyle ilk kez mahkemeye götürüldüğünüzde öğrenirsiniz.

Git bu modelde iyi çalışmıyor. Daha küçük bir şirketiniz veya VPN erişimi zayıf bir şirketiniz varsa, burası gerçekten parlıyor.

5
aflat

Çoğu büyük şirketin Perforce'yi kullanmasının bir nedeni, BT departmanında bu konuda çok fazla bilgiye sahip olan ve bununla ilgili sorunların giderilmesinde yılların tecrübesi olan daha fazla profesyonel olması olabilir.

Gelecekte şirketlerin Perforce'den uzaklaşıp GIT'e doğru daha fazla hareket etmeye başlayabileceğini hissediyorum ... tanıdığım çoğu geliştirici bunu tercih ediyor gibi görünüyor !! Ayrıca, Performance'ın önümüzdeki yıllarda neden bu kadar baskın olmayabileceğine dair daha fazla kanıt için http://whygitisbetterthanx.com/#git-is-fast adresine göz atın!

4
rrazd

Bazı zamanlar önce, bir dizi VCS'den (RCS, CVS, ClearCase, Perforce'nin daha önce kullanıldığından eminim, başkaları da olabilirdi) kullanımdaki benzersiz sistem olarak Performans'a geçtik. Bu küçük bir proje değildi: göç bir yıldan fazla sürdü. Sorumlu ekip (onun bir parçası değildim) birkaç VCS'yi değerlendirdi ve en azından git ve svn, halihazırda kullanımda olanların yanı sıra kabul edildi. Raporlarını hatırladığım gibi, gerekli özelliklere sahip olmayan araçları filtrelediler ve sonra şunları düşündüler:

  • özellikle uzak siteler için tipik kullanım performansı

  • kaynak gereksinimleri

  • çalışma alışkanlığında ihtiyaç duyulan değişikliklerin önemi

  • destek kullanılabilirliği ve maliyeti

ve Perforce genel olarak oldukça açık bir kazanan oldu. git ilk nokta için biraz daha iyiydi, ama diğerleri için dezavantajlıydı.

4
AProgrammer

Bir zamanlar, çok uzun zaman önce (IDE VI olarak adlandırıldığında), tek ücretsiz (açık kaynak) sistemler CVS, RCS ve SCCS idi.

  • Bunların hiçbiri yeniden adlandırılan bir dosyayla bile başa çıkamıyordu.
  • Birleşmeleri kaydetmediler, bu nedenle iki şube aktif olarak çalışıyorsa, bir dalda iş bitene kadar birleştirmek çok zordu.
  • Çok büyük kod tabanlarına iyi ölçeklenmediler
  • Büyük projelerin istediği erişim kontrolü ve süreç muhbirini sağlamadılar.

Orada çok sayıda ticari kaynak kodu kontrol sistemi vardı, bunların çoğu tek bir makine satıcısı (IBM, DEC, HP, vb.) Tarafından sağlandı ve sadece donanımlarında çalıştırıldı.

Daha sonra birkaç şirket, Perforce ve ClearCase dahil olmak üzere platformlar arası ticari kaynak kodu kontrolü sattığını belirtti.

ClearCase, çok sayıda küçük ağ paketinin "yuvarlak açılmış" olması nedeniyle geniş alan ağlarında (ancak internette) iyi çalışmayan RPC üzerine inşa edildi, ayrıca IBM ve rasyonel ClearCase'i bir “nakit inek” olarak gördü ve asla çok fazla göstermedi Aşk.

Bu yüzden hala yaygın olarak kullanılan tek “eski” ticari kaynak kodu kontrol sistemleri Perforce'dir. Performans bir kez kullanıldığında ve inşa sistemleri ve hata izleme sistemlerine entegre edildikten sonra, bir şirketin başka bir şeye geçmesi için çok az kısa vadeli fayda vardır.

Özetlemek gerekirse, performans başka birçok seçenek olmadığında “kapıdaki ayak” ı aldı ve insanları bundan uzaklaştıracak kadar dağınık değiller.

3
Ian