Dlaczego duże firmy korzystają z Perforce? [Zamknięte]

113

Słyszałem o niektórych dużych firmach, np. Google, Facebook używają Perforce

Czy jest jakiś powód, dla którego SVN / Git nie może zastąpić Perforce?

34401
źródło
34
Słyszałem, że Google używa folderów o nazwie datownika na udostępnionym dysku! ;)
FrustratedWithFormsDesigner
10
Tylko wspólny dysk korzysta z MapReduce, więc są fajne
Paul Stovell,
4
Dużym problemem będzie wsparcie. Przy zakupie siłą rzeczy kupujesz wsparcie od dewelopera systemu, coś, co może nie dostać z Git.
ChrisF
12
@Anto: Kogo obchodzi to, co mówi Linus? To, że jesteś genialnym programistą jądra, nie oznacza, że ​​wiesz wszystko o wszystkim.
Billy ONeal
5
Właśnie przybyłem z Konferencji Użytkowników Perforce 2 tygodnie temu i mogę powiedzieć, że Google używa perforce. Otrzymują ponad 10 000 zgłoszeń dziennie na 1 serwer.
południu

Odpowiedzi:

83

Uzasadnienie jest być może mniej istotne niż kiedyś, ale Perforce ma większą wydajność na dużych repozytoriach niż Subversion. Jest to jeden z powodów, dla których Microsoft nabył licencję źródłową dla Perforce na budowę Source Depot; Repozytorium NT jest potworem i niewiele produktów, komercyjnych lub innych, mogłoby sobie z tym poradzić.

Ponadto, przynajmniej kiedyś, wizualne narzędzia Perforce były znacznie lepsze niż to, co jest dostępne po wyjęciu z pudełka (że tak powiem) z Subversion lub Git. Jeśli używasz Melda, być może te rzeczy mają mniejsze znaczenie niż kiedyś, ale wciąż jest kilka rzeczy, które Perforce zrobił bardzo ładnie, w tym wizualizacje rozgałęzień i scalania, o których, chociaż nie mam szczegółowej pamięci, odkąd zostały około 3 lata od ostatniego dotknięcia Perforce wydawały się bardziej wyrafinowane niż, na przykład, podejście Githuba do tego.

Po skorzystaniu z Perforce możesz zrozumieć, jakie są jego zalety w praktyce. Od dawna oferują bezpłatną opcję serwera dla dwóch użytkowników, a w zależności od systemów zarządzania kodem źródłowym, z którymi masz doświadczenie, może być warto kosztować aktualizacji po tym, jak Twój zespół przetestuje go przez jakiś czas. W przypadku mniejszych sklepów to, plus efekty sieciowe programistów, którzy go używali i polubili, są powodem, dla którego Perforce zyskuje płacących użytkowników. W przeciwieństwie do cynicznych uwag Dmitrija, prawdopodobnie nie ma zbyt wielu wygranych i posiłków dla CTO, aby sprzedawać Perforce w firmach z małymi zespołami programistycznymi.

Większość projektów, nad którymi pracowałem poza Microsoftem, może być dość dobrze obsługiwanych przez Git, Mercurial lub Subversion, i powiedziałbym, że większość firm, w których pracowałem, używa jednej z tych opcji. Ale jest pewna słaba strona, zwykle połączenie wielkości repozytorium, modelu rozgałęziania i scalania oraz doświadczenia / historii zespołu, które prowadzą ludzi do korzystania z narzędzi komercyjnych. Na przykład rzadko widywałem duże repozytoria Git. Może to nie wynikać z wewnętrznych ograniczeń Git; Przyznaję, że jestem tego całkowicie nieświadomy. Ale w niektórych projektach (takich jak Windows NT) mogą istnieć pewne praktyczne ograniczenia bezpłatnych rozwiązań.

JasonTrue
źródło
3
Dziękujemy za udzielenie rozsądnej odpowiedzi oprócz cynicznej teorii „wino i obiad”. To może być prawdą dla wielu firm, ale tam jakieś legit powodów, że firmy idą z Perforce (lub przepisać to: P). Nie mogę sobie wyobrazić próby obsługi źródła NT w SVN. To prawda, że ​​SVN i Git nadrabiają zaległości i być może w przypadku nowego dużego projektu jedna z nich jest właściwą decyzją. Pomyśl jednak o kosztach związanych z przeniesieniem projektu na żywo tak dużego jak Windows (wszystkie wersje) z jednego systemu kontroli źródła do drugiego. Nie jest to warte kosztów, szczególnie gdy działa obecny system kontroli źródła.
Greg Jackson
1
W rzeczywistości przeszli z SLM (narzędzie wewnętrzne) do Source Depot (rozwidlenie Perforce), więc prawdopodobnie w takim przypadku ktoś byłby tego wart. Ale tak, nie jest to warte kosztu, chyba że istnieją znaczne korzyści.
JasonTrue
1
talk.fogcreek.com/joelonsoftware/... ma trochę tej historii z głównie zewnętrznych źródeł. (Jestem outsiderem od 2004 roku, FWIW).
JasonTrue
3
Nie jestem pewien dużej sytuacji repo. Zarządzam jednym, jest to repozytorium 12 Gb (tzn. Katalog skompresowanego serwera to 12 Gb) i zawiera 320 000 wersji. Jest wystarczająco szybki. Są szanse, że Microsoft użył Perforce, ponieważ SVN nie istniał jeszcze w 1999 roku. Maillist.perforce.com/pipermail/perforce-user/2001-August/… i subversion.apache.org/docs/release-notes/release-history.html
gbjbaanb
8
@ gbjbaanb, to nie jest duże repozytorium ... w dzisiejszych czasach liczy się jako średniej wielkości. ;) Zobacz np. Research.google.com/pubs/archive/34459.pdf
Alex Feinman
65

Jestem dość biegły w svn, git i Perforce, zarówno jako użytkownik, jak i przy konfigurowaniu i utrzymywaniu serwerów.

Dla firmy, a nawet samotnego programisty, takiego jak ja, kontrola źródła jest kosztem poniesionym na wsparcie działalności polegającej na zarabianiu pieniędzy, która polega na opracowywaniu i sprzedaży kodu. Dlatego należy wziąć pod uwagę kilka czynników:

  • Jak dobrze pasuje do twojego modelu programistycznego?
  • Jak łatwo programiści mogą się uczyć i używać?
  • Czy rutynowe operacje dla programistów są szybkie?
  • Czy proces używania go odwraca uwagę od ich prawdziwej pracy, jaką jest pisanie kodu?
  • Jak łatwo jest skonfigurować i utrzymywać?
  • Ile kosztuje zakup i utrzymanie?
  • Jeśli potrzebujesz pomocy, jak łatwo ją zdobyć?

Pominę szczegóły tl: dr na temat zalet i wad poszczególnych systemów. Wystarczy powiedzieć, że kiedy wróciłem do konsultacji w pełnym wymiarze godzin w zeszłym roku, przejrzałem wszystkie trzy, aby zdecydować, które pozwolą mi jak najszybciej zarobić jak najwięcej pieniędzy, dostarczając wysokiej jakości oprogramowanie moim klientom i nie wymagając dużo niepłatnych wygłupiać. Kiedy wziąłem pod uwagę polityczną opinię, że „FOSS jest dobry, a nie-FOSS jest zły” z równania, skończyło się na tym, że starałem się o licencję Perforce.

I dlatego duże firmy wybierają również Perforce.


Oto szczegóły tl: dr z komentarzy oraz trochę więcej.

Adresowanie svn jest łatwe: w porównaniu z Perforce jest powolne. Pracowałem w firmie, która osadziła Linuksa na telefony komórkowe, a nasze pełne źródła dysponowały 9 GB; używali Perforce. Po otrzymaniu kodu aktualizacja najnowszych źródeł zwykle zajmuje kilka sekund w sieci LAN lub kilka minut przez połączenie VPN z mojego domu. W przypadku svn byłyby to odpowiednio minuty i godziny.

git vs. Perforce jest bardziej skomplikowany. Wiele firm uważa, że ​​mają dobre powody biznesowe, aby korzystać ze scentralizowanego repozytorium z kontrolą dostępu, aby ułatwić dokonywanie zleceń i utrudnić wykonywanie innych czynności - a Perforce idealnie pasuje do tego modelu. Jednak git pozytywnie zachęca ludzi do pracy w lokalnym oddziale i nie ma sposobu, aby działał inaczej. Deweloper może pracować całkowicie w lokalnym oddziale i nigdy nie angażować się w centralne repozytorium - więc jeśli firma nie chce, aby ludzie tak pracowali, Perforce jest lepszą opcją.

Istnieją inne problemy z git dla niektórych potrzeb biznesowych. Pracowałem w firmie, która korzystała z git i nie wiem, ile razy słyszałem tę dyskusję: „Chciałbym, żebyśmy korzystali z [innych VCS], ponieważ muszę to zrobić i nie mogę z git . ” „Oczywiście możesz to zrobić za pomocą git”. "W jaki sposób?" „Cóż, najpierw musisz napisać skrypt bash ...” „Nieważne.”

A potem jest czas, który zajmuje początkowe wypełnienie drzewa źródłowego, które ma wiele historii. Dzięki Perforce, ponieważ historia jest przechowywana na serwerze, po prostu otrzymujesz najnowsze wersje wszystkich plików, więc jest to naprawdę szybkie - nawet skonfigurowanie całego drzewa 9 GB, o którym wspomniałem, zajęło tylko kilka godzin w sieci VPN. Z git może trwać od długiego czasu do wieczności. Czasami muszę sklonować repozytorium git GTK + lub X serwera, a to długa przerwa na lunch, a może czas na spanie.

Naprawdę jest to kwestia odpowiedniego narzędzia do pracy. svn działa dobrze w przypadku większości działań Apple na open source i byłby okropny dla hakowania jądra. git działa świetnie dla GTK +, ale jest niesamowicie powolny do pracy w WebKit - drzewo źródłowe i historia są po prostu zbyt duże (jak dowiedziałem się, jak ciężko pracować z kodem z portalu svn-to-git WebKita). Perforce działa dobrze, jeśli masz gigantyczne drzewo źródeł i potrzebujesz scentralizowanej kontroli. Każdy z nich działa dobrze we właściwym kontekście.

Bob Murphy
źródło
2
Czy problem polega na tym, że duże firmy umieszczają swój kod w jednym repozytorium? Co powiesz na umieszczenie każdego „modułu” lub „aplikacji” w osobnym repozytorium Git, aby zarządzać rozmiarami tych repozytoriów? Każde z tych repozytoriów importowałoby wtedy wymagane funkcje za pomocą funkcji podmoduła Gita. W ten sposób opiekunowie repozytoriów od czasu pulldo czasu ich podmoduły uzyskiwali aktualizacje lub nowe funkcje, a dopiero wtedy użytkownicy tego repozytorium wymagali aktualizacji większych niż kod samego repozytorium.
Carl G
@Cll G: Jeśli przeczytasz wszystkie odpowiedzi tutaj, znajdziesz wiele powodów, dla których ludzie wybrali Perforce zamiast git, które nie mają nic wspólnego z możliwościami git wokół repozytoriów lub podmodułów.
Bob Murphy,
Próbowałem zająć się „czasem potrzebnym do początkowego zapełnienia drzewa źródłowego, które”, ale w rzeczywistości widzę, że problem podmodułu, o którym wspomniałem, jest nieistotny, ponieważ podmoduły zawierają również wszystkie historie tych repozytoriów. Wydaje mi się, że jedynym sposobem na ograniczenie historii byłoby użycie plików binarnych zależności.
Carl G
Cóż, z git możesz zrobić płytki klon i uzyskać tylko niewielką ilość historii, a może tylko najnowsze pliki (git clone - głębokość 1). Działa to również w przypadku podmodułów git.
Sahil Singh
38

Zwłaszcza GIT, a SVN do pewnego stopnia nie jest już tak stary - jeśli potrzebowałeś solidnej kontroli wersji w połowie lat 90., prawie musiałeś zacząć działać komercyjnie, ponieważ SVN był w powijakach, a CVS był, cóż, CVS. Kiedy już zainwestujesz dużo w system, przeniesienie go może być niedźwiedziem.

Och, a faceci, którzy podejmują te decyzje, prawdopodobnie nigdy nie wchodzą w interakcje z systemem kontroli wersji, ale wygrywają i jedzą wspomniani wcześniej sprzedawcy.

Wyatt Barnett
źródło
4
+1. Stosunkowo niedawno przeszliśmy na git i musieliśmy biegać dość długo - tylko dlatego, że wszystko inne było gorsze.
9000
11
Chociaż IMO Perforce marnuje dużo czasu. Nadal używamy go w pracy, ponieważ zainwestowaliśmy czas w opracowywanie niestandardowych narzędzi, które z nim współpracują. Aby przełączyć, musielibyśmy przebudować te narzędzia.
m4tt1mus
2
Perforci i nieświadomi programiści sprawili, że nienawidzę sprawdzania kodu. Wolałbym pisać kod kredką i skompilować to .
Jim Schubert
Myślę, że powinieneś rzucić okiem na perforce przed komentowaniem.
Toby Allen,
30

Od prawie 9 lat jestem programistą w branży gier i każdy projekt, nad którym kiedykolwiek pracowałem, wykorzystywał Perforce. Podejrzewam, że jest kilka rzeczy, które utrzymują Perforce w użyciu w tej konkretnej branży.

  • Ludzie używają Perforce od dłuższego czasu i czują się z tym komfortowo, przez co wahają się przed przejściem na inne rozwiązanie. Decydenci mogą również wahać się, czy oddać swój projekt o wartości 30 milionów dolarów w ręce oprogramowania, z którego nigdy wcześniej nie korzystali.
  • Wiele firm / zespołów dodało obsługę Perforce do swoich wewnętrznych narzędzi, co może wymagać znacznej pracy, aby zaktualizować obsługę innego VCS.
  • Podczas gdy programiści mogą łatwo przestawić się na inną Git / Hg / SVN, jest wielu mniej technicznych członków zespołu tworzącego gry, takich jak artyści, projektanci i producenci. Zapewnienie im komfortu dzięki nowemu systemowi może zająć dużo czasu i byłbym skłonny się założyć, że byliby dość odporni na zmianę.
Mike O'Connor
źródło
19
Myślę, że „starzy” programiści (+10 lat) są prawdopodobnie tak samo odporni na zmiany jak ludzie „nietechniczni”.
Wayne Werner
3
+1 na to, specjalnie dla tej branży. Programiści gier wideo mają na ogół tyle rzeczy na głowie, że zmiana infrastruktury, z którą pracują, jest przerażającą propozycją. „Jeśli nie jest zepsute ...” to trochę mantra i często uniemożliwia branży przejście od starszych rozwiązań, nawet jeśli mogą być bardziej odpowiednie.
Chris Subagio
2
@Wayne - całkowicie ageistyczny komentarz. Mam ponad sześćdziesiąt lat i jestem głównym zwolennikiem zmian i innowacji w mojej średniej i dużej witrynie. James Gosling miał 46 lat, kiedy zaczął pisać pierwszą maszynę JVM. Ken Thomson miał 49 lat, kiedy wymyślił schemat kodowania UTF-8, i 63, kiedy zaczął pracować nad językiem GO.
James Anderson
1
@JamesAnderson Myślę, że prawdopodobnie tam jesteś. A jeśli Twoja organizacja nie ma kultury doskonalenia, zobaczysz, że wchodzi w grę efekt Morza Martwego . Zastanawiam się, czy można zmienić system jako całość, czy możemy tylko majstrować przy naszej małej części.
Wayne Werner
2
@ MikeO'Connor Zapomniałeś również, że gry wykorzystują wiele zasobów binarnych. Możliwość blokowania wyłącznie zasobów binarnych to OGROMNY plus.
CodingMadeEasy
22

Może może lubią Perforce, ponieważ Perforce jest lepszy?

  • Perforce jest szybki. Znacznie szybszy niż Subversion czy Git.
  • Łączenie na siłę jest lepsze niż Subversion lub Git. Git tak naprawdę nie łączy, a śledzenie wersji Subversion nie jest tak dobre, przynajmniej w wersji 1.5.
  • Perforce ma doskonałą obsługę klienta.
  • Perforce łączy rewizję repozytorium Subversion z indywidualnymi wersjami plików. Perforce umożliwia przeglądanie wersji repozytorium za pomocą list zmian lub indywidualnych wersji plików.
  • Perforce wykonuje znacznie lepszą pracę z wieloma listami zmian niż Subversion. Listy zmian Subversion są nieco później przemyślane i znam niewielu, którzy z nich korzystają. Perforce jest wbudowany. Jeśli przeniesiesz zmieniony plik z domyślnej listy zmian, nie zostanie on przypadkowo zatwierdzony.
  • Perforce pozwala określić układ katalogu roboczego. Na przykład, jeśli masz standardowe drzewo katalogów kodu źródłowego, ale niektórzy klienci mają niestandardowe źródło, możesz nałożyć niestandardowe źródło na standardowe drzewo. Możesz łatwo robić rzadkie kasy, określając tylko te elementy, które chcesz zrealizować.

Dobra, zanim pomyślisz, że jestem fanem Perforce, ostatni raz poleciłem Perforce firmie ponad siedem lat temu. Perforce kosztuje 800 USD za licencję - co jest tanie w porównaniu z ClearCase, ale znacznie droższe w porównaniu z Subversion. Mam trudności z uzasadnieniem Perforce nad Subversion.

Ponadto większość programistów korzysta z Subversion. Nie chcą się uczyć Perforce, który ma inny sposób działania niż Subversion. W Perforce musisz utworzyć klienta i oznaczyć pliki do edycji, zanim będziesz mógł je zmodyfikować. Nie musisz tego robić z Subversion.

Istnieje również mniej integracji z Perforce nad Subversion. Częściowo wynika to z użytkowania klienta . Po prostu nie działa dobrze z VisualStudio lub nawet Hudsonem. Częściowo wynika to z faktu, że Perforce musi tworzyć integracje klienta.

Koszt licencji praw własności wywołuje koszt administracyjny. Wyobraź sobie, że możesz licencjonować oprogramowanie za 1,00 USD za użytkownika. Cholera, zróbmy dwa bity. Tysiące licencji kosztuje tylko 250 USD.

Teraz potrzebujesz pełnoetatowej osoby zarządzającej licencją. Przeciętny pracownik techniczny pozostaje w firmie przez około 2 lata. Oznacza to, że każdego roku wyjedzie 500 osób, a kolejnych 500 przyjedzie. Każdego tygodnia dziesięć osób musi zmienić licencję. Są chwile, kiedy projekt zaczyna się i potrzebujesz kolejnych 250 licencji. Te muszą być zamówione, wprowadzone i utrzymane. To może potrwać tygodnie.

Dlatego wiele firm komercyjnych przeszło na oprogramowanie typu open source. To nie jest koszt licencji. Płacisz programistom 150 000 USD rocznie, co to jest kolejne 800 USD za licencję Perforce? Zarządza tą licencją. Perforce wygląda świetnie w porównaniu z ClearCase: szybciej, łatwiej, taniej, lepiej. Ale przeciwko Subversion? Siła może być szybsza, a może i lepsza, ale czy jest o 800 USD lepsza? Czy lepiej zarządza licencją? Czy nie używa lepszego pożądanego narzędzia?

Dlatego Perforce może mieć problemy.

Git nie jest ostatecznym narzędziem. Działa świetnie w sytuacjach, gdy nie chcesz scentralizowanej kontroli nad tym, kto ma dostęp do repozytorium. Ale może to być ból w wielu okolicznościach. Mówię tak:

  1. Prowadzisz projekt typu open source. Czy byłbyś szczęśliwy lub zdenerwowany, gdyby milion osób posiadało kopię całego Twojego repozytorium?
  2. Prowadzisz biuro handlu finansowego, które korzysta z zastrzeżonego oprogramowania, aby uzyskać przewagę nad konkurencją. Czy byłbyś szczęśliwy lub zdenerwowany, gdyby milion osób posiadało kopię całego Twojego repozytorium?

Jeśli wykonujesz scentralizowane kompilacje, wszyscy i tak powinni korzystać z jednego repozytorium. Jakie są zalety systemu rozproszonego w takich okolicznościach? W rzeczywistości może zachęcać ludzi do pracy offline . Programiści mogą po prostu pójść swoją własną wesołą drogą i nie popełnić niczego do ostatniej chwili. Następnie spędzasz dwa szalone dni, próbując sprawić, by wszystko znów działało.

Nie jestem przeciwko Gitowi. W wielu przypadkach polecałem Git. Należą do nich rozproszone zespoły o słabych połączeniach ze sobą lub miejsca, w których nie chcesz śledzić wszystkich, którzy mają dostęp do repozytorium źródłowego.

Na przykład wydział informatyki na uczelni chciał, aby ich uczniowie korzystali z kontroli źródła i umieścili tam swój kod, aby nauczyciele mogli je obejrzeć. Świetny pomysł. Zbyt wiele dzieci kończy naukę bez zrozumienia standardowych procedur budowania i rozwoju. Poleciłem Git.

Korzystając z Git, administrator repozytorium musi jedynie przyjmować zatwierdzenia od innych profesorów. Nie muszą się martwić o poszczególnych uczniów. Profesorowie mogą pozwolić uczniom na zaakceptowanie ich wersji repozytorium. Uczniowie mogą pracować w grupach, a każda grupa może udostępniać swoją wersję repozytorium.

Gdyby uczelnia korzystała z Subversion, ktoś musiałby znać wszystkich studentów i dać im dostęp do centralnego repozytorium. Musieliby zarządzać, kto może sprawdzić, co i gdzie. Jeśli profesor przypisał projekt grupowy, należałoby go skonfigurować i zarządzać. Potrzebowałbyś osoby pełnoetatowej, żeby sobie z tym poradzić.

To nie jest mecz piłkarski, w którym jedna drużyna jest lepsza od drugiej. Narzędzia działają na różne sposoby, a każdy z nich ma swoje zalety i wady. Perforce to świetne narzędzie. Niestety, pojawiły się okoliczności, które sprawiają, że trudno go polecić.

Git jest świetny, ale wciąż wracam do Subversion dla mojego osobistego repozytorium źródeł. W końcu nie udostępniam go, a Subversion jest po prostu łatwiejszy w użyciu. Używam Gita do pracy osobistej, jeśli mam mały zespół, ponieważ nie muszę utrzymywać mojego repozytorium przez cały czas w Internecie. W przypadku większości witryn komercyjnych nadal uważam, że Subversion działa najlepiej. Ale są okoliczności, w których Git świeci.

David W.
źródło
40
Czekaj, co? Zgubiłeś mnie tutaj „Łączenie w trybie Perforce jest lepsze niż Subversion lub Git. Git tak naprawdę nie robi scalania [...]”. Czy możesz to wyjaśnić?
Sverre Rabbelier
1
W rzeczywistości uważam, że Git jest całkiem dobry do łączenia, przyjemniejszy niż oldschoolowe narzędzia SCM, ale kiedy w svn brakuje mi możliwości umieszczenia rzeczy w liście zmian „nie melduj się”, jak to często robiłem z Perforce. (Próbowałem to zrobić w SVN, ale mimo to ostatecznie przypadkowo to sprawdziłem, ponieważ listy zmian svn i p4 zachowują się inaczej).
JasonTrue
12
@SverreRabbelier 3 lata później, a ludzie wciąż czekają na odpowiedź na twoje pytanie.
Navin
1
„ponieważ Perforce jest lepszy”… „To nie jest mecz piłkarski, w którym jedna drużyna jest lepsza od drugiej”. ...
RJFalconer
4
perforce jest szybki. znacznie szybciej niż svn lub git. --- benchmarki, albo tak się nie stało ...; p
sjas
14

Nie wiem, czy przekupstwo „wino i obiad” nadal ma zastosowanie, ale dla większości menedżerów, którzy decydują się na znalezienie produktu, przeczytają je w różnych publikacjach (skierowanych do kierownictwa) i przejrzą broszury i broszury wychwalające produkty cnoty.

Zgadnij co, produkty FOSS nie pojawiają się w tych miejscach!

Jest więc prawie pewne, że większość decyzji zakupowych kierownictwa wynika z reklamy i marketingu. Mogą przeprowadzać oceny, ale kilku takich produktów.

Drugi powód wynika z dojrzałości. Niektóre produkty, z których korzystamy dzisiaj, są wystarczająco stabilne do poważnego użytku w biznesie, niektóre nie mają opcji wsparcia, niektóre nie mają udokumentowanych osiągnięć jako rozwiązań biznesowych. Są to ważne rzeczy do rozważenia (chociaż jako technik chętnie ocenię rozwiązania FOSS, jeśli ryzyko ich użycia i ich porażki jest minimalne, aby utrzymać działalność firmy), a niektórzy menedżerowie słusznie obawiają się ich nie mieć. Są odpowiedzialni przed swoimi szefami i czują się znacznie bardziej komfortowo, jeśli za produktem stoi organizacja wsparcia - w końcu masz taką dla swojej firmy.

Wreszcie, podczas gdy wiele produktów FOSS ma za sobą wsparcie (pomyśl Collabnet lub Wandisco dla SVN), nadal zyskuje reputację „zrobione przez maniaków w ich tylnej sypialni”. Wszyscy wiemy, że jest to ogólnie b * * ** t, a najlepszy FOSS niewiarygodnie dobrze konkuruje z ofertami komercyjnymi, ale mój menadżer nadal musi być przekonany. może po prostu nie zdaje sobie sprawy z różnicy między niedojrzałymi i dojrzałymi produktami FOSS; może go to nie obchodzi.

W każdym razie Perforce jest dobrym SCM, nie ma powodu, aby go nie wybierać. Mógłbym powiedzieć to samo w przypadku innych SCM, ale znowu mogę powiedzieć tylko złe rzeczy o niektórych innych i wciąż mam koszmary, jeśli chodzi o kilka produktów.

gbjbaanb
źródło
To był bardziej przekonujący argument dziesięć lat temu, ale wiele produktów FOSS jest dziś w głównym nurcie; w tym SVN, który jest używany w niektórych dużych firmach.
Jeremy
Nie obchodzi mnie, że FOSS ma odpowiednie rzeczy do konkurowania - dbam o to, że mój menedżer uważa, że nie. Poza tym niektóre duże firmy poruszają się powoli, więc wciąż się tam dostają, kilka z nich zajmie jeszcze kilka lat, aby rozważyć ocenę produktów FOSS.
gbjbaanb
gbjbaanb Nie zrozumiałeś mnie. Nie sądzę, by czynniki, które opisujesz, były tak samo istotne na każdym szczeblu zarządzania, jak dziesięć lat temu. Chociaż taka może być Twoja sytuacja, uogólnienie byłoby błędem. FOSS jest głównym nurtem, co oznacza, że jest stosowany przez większość dużych firm i stosowany w podstawowych systemach.
Jeremy
6
Myślę, że jest to kluczowa kwestia: narzędzia FOSS nie reklamują się, naprawdę, ponieważ nie mają powodu. Częścią tego są broszury i rzeczy, o których wspominasz, ale nawet jeśli Google „porównuje systemy SCM” lub „porównawczy system kontroli wersji”, jedyne rzeczy, które znajduję, to te wykonane przez Perforce. Jasne, muszę wziąć pod uwagę źródło, ale nie wiem, czy narzędzia FOSS starają się reklamować i mówić o tym, dlaczego są najlepsze. Wiem, że nie doceniamy komercji, ale czasami marketing i reklama pomagają mi dokonać świadomego wyboru.
Szansa
1
Myślę, że istnieją dwa doskonałe powody, aby nie wybierać opcji Perforce: 1. Rozgałęzienie jest bardzo kosztowne, oraz 2. Proces pobierania i edycji sprawia, że ​​praca offline jest bardzo trudna do pogodzenia.
kevin cline
14

Ponieważ narzędzia takie jak Perforce mają sprzedawców wina i jedzą ludzi odpowiedzialnych za zakupy, podczas gdy Git tego nie robi. Oczywiście, to tylko cyniczna strona mojego mówienia, ale jest to cynizm wywołany widzeniem procesu z bliska.

Żeby było to całkowicie jasne: nie mam na myśli, że za każdym razem, gdy zobaczysz, jak Twój CIO potknie się pijany korytarzem, spodziewaj się, że w następnym kwartale będziesz używać nowego systemu kontroli wersji. Tyle, że w wielu organizacjach istnieje rozbieżność między użytkowaniem a nabywaniem. Oczywiście istnieją inne powody, dla których firmy korzystają z Perforce: na przykład mogły już dużo zainwestować w jego wdrożenie w swoim przepływie pracy. Ale ogólnie --- i to pytanie jest bardzo ogólne --- nie ma korzyści funkcjonalnej, że nie używa się narzędzi FOSS.

Dmitri
źródło
13
Może to zabrzmieć cynicznie, ale w gruncie rzeczy trafiłeś w gwoździe. We własnej firmie walczę o promowanie dowolnego rozwiązania FOSS, ponieważ exec ma wrażenie, że jeśli jest za darmo, nie może być dobry.
wolfgangsz
1
w związku z tym, chociaż mogłem je trochę przekształcić, gdy zastąpiliśmy nasze rozwiązanie SVN rozwiązaniem „korporacyjnym”, które kosztowało przewrotną fortunę, wymagało od konsultantów, 2 kontrahentów do administrowania nim, a po wielu lamentach, zgrzytaniu zębami, błędnym działaniu i śmierć naszej produktywności ... została wyrzucona i zastąpiona naszym starym rozwiązaniem SVN.
gbjbaanb
7
Google nie jest tak naprawdę znany z tego rodzaju kultury.
Jeremy
11
@Chance: Do jakich rzeczy kontaktujesz się z pomocą techniczną? Korzystałem z CVS, Subversion i Mercurial i nigdy nie miałem ochoty na kogoś, do kogo mógłbym zadzwonić. Jeśli mam problem, google lub wysyłam pytanie, które zostało rozwiązane, zwykle za kilka minut. Sugeruję, że narzędzie kontroli źródła, które wymaga wsparcia twórcy systemu, ma poważny problem.
Tom Anderson
2
@TobyAllen: nie przez około sześć lat (nota datę pytanie) ale w dzisiejszych czasach to wygląda nawet Perforce chce użyć czegoś innego niż Perforce: perforce.com/git
Dmitri
12

Prawdopodobnie z tego samego powodu, dla którego moja firma odmawia korzystania z wielu programów typu open source (nie zgadzam się):

Kiedy coś pójdzie nie tak, chcą kogoś, do kogo mogą zadzwonić i krzyczeć.

Michael
źródło
2
Zgadzam się: to duży powód dla wielu działów IT, ale wydaje się niedojrzały. „To nie nasza wina, to ICH WADA”. Wybór gorszego produktu tylko z powodu możliwości „wskazywania palcem od jednej szyi do drugiej” wydaje się dziecinną decyzją. Nie dlatego, że nie jest często robiony, po prostu wydaje się dziecinny.
Bruce Ediger,
Twoja odpowiedź nie dotyczy wsparcia technicznego Perforce. Szkoda, bo gdybyś wiedział, jak to było dobre, Twoja odpowiedź mogłaby nie pojawić się. Wsparcie techniczne Perforce jest znakomite i oddane, a oni naprawiają SZYBKO.
Br.Bill
9

Podczas gdy wszystkie odpowiedzi mówią o dużych firmach korzystających z P4 (i odpowiadają, dlaczego Google używał P4), jednym z głównych powodów, dla których Google nadal korzysta z Perforce, jest to, że Perforce pozwala ci sprawdzić poddrzewo repozytorium, podczas gdy nie możesz tego zrobić za pomocą Git. Dzięki dużym repozytoriom źródeł, takim jak Google, zrobiło to ogromną różnicę.

I o ile słyszałem, Facebook używa SVN i Git-SVN

manojlds
źródło
1
Absolutnie subrepos zachęcają i ułatwiają ponowne użycie kodu. Właśnie dlatego wybieram Perforce, kiedy mam głos w tej sprawie. Wielka rzecz! Z łatwością miksuj i dopasowuj kod z różnych repozytoriów (subrepos hg), śledząc, kto używa konkretnego subrepo, możliwość łatwego śledzenia checkinów, rozgałęzień i scalania wszystkich repozytoriów. Cały czas czyni to bardzo prostym dla programisty końcowego dzięki specyfikacji klienta z jedną linią i zachowuje szczegóły w specyfikacji oddziału dla superużytkowników. W tej chwili jestem zmuszony używać Mercurial przy dużym projekcie, a zajmowanie się sup-repo za pomocą hg kosztuje DUŻO pieniędzy utraconą produktywnością.
stephenmm
8

Ponieważ SVN jest, no cóż, SVN i Perforce (od czasu, gdy 4 lata temu przy porównywaniu narzędzi) robi pewne rzeczy lepiej niż SVN . (Myślę, że rozgałęzienie jest jednym z nich.)

A GIT jest Dvcs, podobnie jak w dystrybucji . Dla zespołów firmowych część rozproszona może być czymś, na co nie zależy ani nie chce.

Martin Ba
źródło
5
Możesz używać Git dobrze z różnymi przepływami pracy, więc dystrybucja nie stanowi problemu ... chyba że zespół firmy nie ma pojęcia. whygitisbetterthanx.com/#any-workflow
M. Dudley,
2
Nie powiedziałbym, że Perforce dobrze rozgałęzia się ... tworzenie oddziałów Perforce powoduje zajętą ​​kopię wszystkiego, co rozgałęzione. SVN rozgałęzia się według leniwej kopii, więc rozgałęzia się znacznie szybciej.
kevin cline
1
@Jason - rozgałęzienie przy subwersji odbywa się szybciej niż mogę wpisać: „svn cp ...; svn switch ...” Na perforce tworzenie gałęzi jest niesamowicie skomplikowane; utwórz specyfikację gałęzi, utwórz przestrzeń roboczą, zintegruj, zatwierdź. Cholera, z perforacją wszystko tak wygląda. Bez szybkiego i łatwego rozgałęziania uważam RCS za zasadniczo bezużyteczny. Sądząc po natężeniu ruchu sieciowego i szybkości ulepszeń, wygląda na to, że Perforce jest produktem wycofanym z eksploatacji.
kevin cline
1
@kevin, nie jestem pewien, jak sobie radzisz z rozgałęzianiem, ale po prostu wykonuję integrację, zatwierdzam część. Nigdy nie stworzyłem specyfikacji gałęzi i nigdy nie musiałem tworzyć obszaru roboczego do rozgałęzienia (chociaż mogłem musiałem zmienić mapowanie widoku, jeśli zdecydowałem się wykluczyć katalogi z mojego widoku). Biorąc to pod uwagę, nie zrobiłem nic z svn, więc nie mogę komentować tego aspektu.
Szansa
1
@kevin: Wiesz, czy coś „działa lepiej” niekoniecznie jest funkcją liczby poleceń CLI potrzebnych do tego. Tylko komentarz kogoś, kto nie jest biegły ani w SVN, ani w Perforce.
Martin Ba
6

Kolejny powód, dla którego duże firmy kupują duże, nieporęczne, „korporacyjne” systemy kontroli wersji:

Kierownictwo średniego i wyższego szczebla w działach IT postrzega VCS jako coś, z czego korzysta każdy projekt, lub można go egzekwować. Gdy już narzucisz użycie VCS, dlaczego nie wprowadzić tam również małego „procesu”? Mam na myśli możliwość określenia systemu „dla całego przedsiębiorstwa”, dlaczego nie przejąć go pod centralną kontrolą, i dodać „odzyskiwanie po awarii” i niektóre „funkcje przepływu pracy”, aby można było powiedzieć „Jesteśmy StraightJacket na poziomie CMM” zgodny!". VCS jest po prostu zbyt łatwym celem, aby wprowadzić funkcje wymuszania przepływu pracy, oto co sprowadza.

Jeśli chodzi o wybór jakiegoś dziwacznego, nieprzyzwoitego oprogramowania (Serena Dimensions), mówi się, że kilka rund bikini Golf na Bahamach z kilkoma 20-osobowymi sprzedawczyniami może przekonać dyrektora lub wiceprezesa o wszystkim.

Bruce Ediger
źródło
bez komentarza, ale chcę wiedzieć, który z naszych kontrahentów lub menedżerów zagrał w bikini w golfa!
gbjbaanb
5
Przyznaję, Bikini Golf pewnie też by na mnie działało.
jhocking
5

Duże firmy potrzebują pewnego rodzaju scentralizowanego modelu. Gdy programiści skończą programowanie, zostaje przekazany do obsługi klienta. Czy naprawdę chcesz być w butach wspierających, gdy muszą przeczesywać 50-200 rozproszonych repozytoriów programistów? Kompilacje są wykonywane w oparciu o centralne repozytorium, kompilacje muszą zawsze, zawsze, zawsze być identyfikowalne i odtwarzalne. Dowiesz się o tym, kiedy po raz pierwszy zostaniesz postawiony przed sądem z powodu jakiegoś głupiego naruszenia patentu.

Git nie działa tak dobrze w tym modelu. Jeśli masz mniejszą firmę lub taką, która ma słaby dostęp do VPN, to właśnie tam naprawdę świeci.

mieszkanie
źródło
2
Najważniejsze jest zdefiniowanie przepływu pracy, scentralizowanego lub zdecentralizowanego. Zadanie wsparcia nie jest łatwiejsze, gdy próbujesz przeczesać 200 oddziałów w centralnym repozytorium. Ogólnie rzecz biorąc, firmy wybierają scentralizowane rozwiązania, ponieważ jest to dla nich wygodne. Nie ma znaczących korzyści w porównaniu z DVCS używanym ze scentralizowanym wspólnym repozytorium.
wadesworld
4

Jednym z powodów, dla których większość dużych firm korzysta z Perforce, może być więcej specjalistów w dziale IT, którzy mają dużą wiedzę na ten temat i mają wieloletnie doświadczenie w rozwiązywaniu problemów z tym związanych.

Wydaje mi się, że w przyszłości firmy mogą zacząć odchodzić od Perforce i bardziej w kierunku GIT ... większość programistów, których znam, wydaje się preferować !! Sprawdź również http://whygitisbetterthanx.com/#git-is-fast w celu uzyskania dalszych dowodów na to, dlaczego Perforce może nie być tak dominujący w nadchodzących latach !!

zrozpaczony
źródło
4

Kilka razy temu przeszliśmy z zestawu VCS (wiem na pewno, że RCS, CVS, ClearCase, Perforce były wcześniej używane, mogą być też inne) na Perforce jako unikalny system w użyciu. To nie był mały projekt: migracja zajęła ponad rok. Zespół (którego nie byłem częścią) ocenił kilka VCS, a przynajmniej git i svn zostały wzięte pod uwagę, a także te już używane. Jak pamiętam ich raport, odfiltrowali narzędzia bez potrzebnych funkcji, a następnie rozważyli:

  • wydajność w typowym użyciu, szczególnie w przypadku witryn zdalnych

  • wymagania dotyczące zasobów

  • znaczenie niezbędnych zmian w nawyku pracy

  • obsługa dostępności i kosztów

a Perforce był całkiem wyraźnym zwycięzcą. git był nieco lepszy dla pierwszego punktu, ale w niekorzystnej sytuacji dla innych.

AProgrammer
źródło
3

Dawno, dawno temu (kiedy IDE nazywało się VI), jedynymi darmowymi (open source) systemami były CVS, RCS i SCCS.

  • Żadna z nich nie poradziłaby sobie nawet dobrze ze zmianą nazwy pliku.
  • Nie rejestrowali połączeń, więc jeśli aktywne były dwie gałęzie, bardzo trudno było je scalić, dopóki prace nie zakończyły się w jednej gałęzi.
  • Nie skalowały się dobrze do bardzo dużych baz kodu
  • Nie zapewniały one poziomu kontroli dostępu i informacji o procesie, którego chcieli duże projekty.

Było wiele komercyjnych systemów kontroli kodu źródłowego, większość z nich została dostarczona przez jednego dostawcę maszyn (IBM, DEC, HP itp.) I działała tylko na ich sprzęcie.

Następnie kilka firm oświadczyło, że sprzedaje komercyjny system kontroli kodu źródłowego na wielu platformach, w tym Perforce i ClearCase.

ClearCase został zbudowany na RPC, który nie działał dobrze w sieciach rozległych (ale tylko w Internecie) z powodu dużej liczby małych pakietów sieciowych, które były „okrągłe”, również IBM i racjonalne postrzegały ClearCase jako „krowę gotówkową” i nigdy nie pokazały tego zbyt wiele miłość.

Zatem jedynym „starym” komercyjnym systemem kontroli kodu źródłowego, który jest nadal w powszechnym użyciu, jest Perforce. Gdy perforce jest używane i zintegrowane z systemami kompilacji i systemami śledzenia błędów, firma ma bardzo niewielkie korzyści krótkoterminowe dla firmy, aby przejść na cokolwiek innego.

Podsumowując, perforce dostało „stopę w drzwi”, gdy nie było wielu innych opcji, a oni nie zrobili jeszcze bałaganu, aby ludzie się od niego oddalili .

Ian
źródło