Pourquoi les grandes entreprises utilisent Perforce? [fermé]


113

J'ai entendu parler de certaines grandes entreprises, par exemple Google et Facebook utilisent Perforce.

Existe-t-il une raison pour laquelle SVN / Git ne peut pas remplacer Perforce?


34
J'ai entendu dire que Google utilisait des dossiers nommés par horodatage sur un lecteur partagé! ;)
FrustratedWithFormsDesigner

10
Seul le lecteur partagé utilise MapReduce, donc ils sont cool
Paul Stovell

4
Un gros problème sera le support. Lorsque vous achetez Perforce, vous achetez de l’assistance du développeur du système, ce que vous n’obtenez peut- être pas de Git.
ChrisF

12
@Anto: Qui se soucie de ce que dit Linus? Ce n’est pas parce que vous êtes un développeur de noyau brillant que vous maîtrisez mieux tout ce que vous êtes.
Billy ONeal

5
Venant tout juste de la conférence des utilisateurs Perforce il y a deux semaines, je peux vous dire que Google utilise forcément. Ils reçoivent plus de 10 000 soumissions par jour sur leur 1 serveur.
aflat

Réponses:


83

La justification est peut-être moins pertinente qu’elle ne l’était auparavant, mais Perforce a tendance à mieux fonctionner sur les grands référentiels que Subversion. C’est l’une des raisons pour lesquelles Microsoft a acquis une licence source auprès de Perforce pour créer Source Depot; Le référentiel de NT est un monstre et peu de produits, commerciaux ou autres, pourraient le gérer.

En outre, au moins une fois, les outils visuels de Perforce étaient bien meilleurs que ceux disponibles (pour ainsi dire) avec Subversion ou Git. Si vous utilisez Meld, ces choses importent peut-être moins qu'avant, mais Perforce a très bien réussi à bien faire certaines choses, notamment les visualisations de ramifications et de fusions, bien que je n'ai pas de mémoire détaillée depuis. Environ trois ans après avoir touché Perforce pour la dernière fois, cela semblait plus sophistiqué que l'approche de Github, par exemple.

Une fois que vous avez utilisé Perforce, vous comprendrez quels sont ses avantages dans la pratique. Ils offrent depuis longtemps une option de serveur gratuit à deux utilisateurs et, en fonction des systèmes de gestion de code source avec lesquels vous avez de l'expérience, vous pouvez constater que le coût de la mise à niveau en vaut la peine, après avoir été testé par votre équipe pendant un certain temps. Pour les plus petits magasins, c’est pour cette raison, ainsi que pour les effets réseau des développeurs qui l’ont utilisé et qui l’a plu, que Perforce finit par avoir des utilisateurs payants. Il n’ya probablement pas beaucoup de gens qui mangent et dînent des CTO pour vendre Perforce dans des entreprises avec de petites équipes de développement, contrairement aux propos cyniques de Dmitri, mais cela est utilisé dans de tels endroits.

La plupart des projets sur lesquels j'ai travaillé en dehors de Microsoft peuvent être raisonnablement bien servis par Git, Mercurial ou Subversion, et je dirais que la majorité des entreprises pour lesquelles j'ai travaillé utilisent l'une de ces options. Mais il existe un point d’intérêt, généralement une combinaison de la taille du référentiel, du modèle de branchement et de fusion, et de l’expérience / de l’histoire d’équipe qui conduit les utilisateurs à utiliser des outils commerciaux. J'ai rarement vu de grands référentiels Git, par exemple. Cela n’est peut-être pas dû aux limitations intrinsèques de Git; Je reconnais l'ignorance totale de cela. Mais dans certains projets (tels que Windows NT), il peut exister des limites pratiques aux solutions libres.


3
Merci de fournir une réponse raisonnable en plus de la théorie cynique du "vin et dîner". C'est peut-être vrai pour beaucoup d'entreprises, mais il y a des raisons légitimes à ce que les entreprises aillent avec Perforce (ou le réécrivent: P). Je ne peux pas imaginer essayer de gérer la source NT en SVN. Il est vrai que SVN et Git sont en train de rattraper leur retard, et peut-être que pour un nouveau grand projet, l'un d'entre eux est la bonne décision. Mais pensez aux coûts associés au déplacement d’un projet réel aussi grand que Windows (toutes les versions) d’un système de contrôle de code source à un autre. Cela ne vaut pas la peine, surtout lorsque le système de contrôle de source actuel fonctionne.
Greg Jackson

1
En fait, ils sont passés de SLM (un outil interne) à Source Depot (une fourchette de Perforce), donc cela valait probablement le coût à quelqu'un dans ce cas. Mais oui, le coût n'en vaut pas la peine, à moins d'un avantage substantiel.
JasonTrue

1
discussion.fogcreek.com/joelonsoftware/… a une partie de cette histoire de sources principalement extérieures. (Je suis un outsider depuis 2004, FWIW).
JasonTrue

3
Je ne suis pas sûr de la grande situation des pensions. J'en gère un, il s'agit d'un rapport de 12 Go (le répertoire du serveur compressé est de 12 Go) et contient 320 000 révisions. C'est assez rapide. Il est fort probable que Microsoft utilise Perforce, car le SVN n’existait pas en 1999. maillist.perforce.com/pipermail/perforce-user/2001-August/… et subversion.apache.org/docs/release-notes/release-history.html
gbjbaanb

8
@gbjbaanb, ce n'est pas un grand référentiel ... de nos jours, il compte comme un dépôt de taille moyenne. ;) Voir par exemple research.google.com/pubs/archive/34459.pdf
Alex Feinman Le

65

Je maîtrise assez bien svn, git et Perforce, tant en tant qu'utilisateur que pour la configuration et la maintenance des serveurs.

Pour une entreprise, voire un programmeur isolé comme moi, le contrôle de la source représente un coût supporté par l'activité génératrice de revenus, qui consiste à développer et à vendre du code. Il y a donc plusieurs facteurs à prendre en compte:

  • Dans quelle mesure cela correspond-il à votre modèle de développement?
  • Est-il facile pour les développeurs d’apprendre et d’utiliser?
  • Les opérations de routine pour les développeurs sont-elles rapides?
  • Le processus d'utilisation est-il une distraction de leur vrai travail, qui consiste à écrire du code?
  • Est-ce facile à installer et à entretenir?
  • Combien coûte l'achat et l'entretien?
  • Si vous avez besoin d'aide, est-il facile de l'obtenir?

Je vais ignorer les détails sur les avantages et les inconvénients des systèmes individuels. Je me contenterai de dire que lorsque je suis revenu à la consultation à temps plein l’année dernière, j’ai passé en revue les trois pour décider lequel me permettrait de gagner le plus d’argent possible en livrant des logiciels de qualité à mes clients, sans nécessiter beaucoup d’impayés. rigoler. Lorsque j'ai pris en compte le fait que "les logiciels libres sont bons et que les non-logiciels libres sont diaboliques", je me suis retrouvé à chercher une licence Perforce.

Et c'est pourquoi les grandes entreprises choisissent également Perforce.


Voici les détails des commentaires, plus un peu plus.

S'adresser à svn est facile: comparé à Perforce, il est lent. J'ai travaillé dans une entreprise qui implémentait Linux pour les téléphones cellulaires et nos sources complètes utilisaient 9 Go; ils ont utilisé Perforce. Une fois que vous avez eu le code, la mise à jour des sources les plus récentes prend normalement quelques secondes sur le réseau local, ou quelques minutes via une connexion VPN de chez moi. Avec svn, c'auraient été minutes et heures respectivement.

git vs. Perforce est plus compliqué. De nombreuses entreprises ont le sentiment qu’elles ont de bonnes raisons d’utiliser un référentiel centralisé avec contrôle de l’accès, de faciliter l’engagement et de ne rien faire d’autre - et Perforce correspond parfaitement à ce modèle. Cependant, git encourage les gens à travailler dans une branche locale et il n’ya aucun moyen de le faire fonctionner différemment. Un développeur peut travailler entièrement dans une branche locale et ne jamais s'engager dans le référentiel central. Par conséquent, si une entreprise ne veut pas que ses collaborateurs travaillent de cette manière, Perforce est une meilleure option.

Il existe d'autres problèmes avec git pour certains besoins de l'entreprise. J'ai travaillé dans une entreprise qui utilisait git, et je ne sais pas combien de fois j'ai entendu cette discussion: "J'aurais aimé utiliser [un autre VCS], car je dois le faire et je ne peux pas avec git . " "Bien sûr, tu peux le faire avec git." "Comment?" "Eh bien, vous devez d'abord écrire un script bash ..." "Ne faites pas attention."

Et puis il y a le temps qu'il faut pour peupler une arborescence source qui a beaucoup d'histoire. Avec Perforce, l'historique étant conservé sur le serveur, vous ne disposez que des versions les plus récentes de tous les fichiers. Il est donc très rapide: même configurer tout cet arbre de 9 Go que j'ai mentionné ne prend que quelques heures sur un VPN. Avec git, cela peut prendre entre un long moment et une éternité. Je dois parfois cloner GTK + ou le dépôt git de serveur X, et c'est une longue pause pour le déjeuner, ou peut-être l'heure du coucher.

En réalité, il s’agit du bon outil pour le poste. svn fonctionne bien pour la plupart des efforts open source d’Apple et serait affreux pour le piratage du noyau. git fonctionne très bien pour GTK +, mais est incroyablement lent pour travailler dans WebKit - l’arbre source et l’historique sont tout simplement trop énormes (car j’ai découvert la difficulté de travailler avec du code du portail svn-to-git de WebKit). Perforce fonctionne bien si vous avez un arbre source géant et avez besoin d’un contrôle centralisé. Chacun d'eux fonctionne bien dans le bon contexte.


2
Le problème est-il que les grandes entreprises mettent leur code dans un référentiel? Qu'en est-il de mettre chaque "module" ou "application" dans un référentiel Git distinct, afin que les tailles de ces référentiels soient gérables? Chacun de ces référentiels importerait ensuite les fonctionnalités requises à l'aide de la fonctionnalité de sous-module de Git. De cette manière, les responsables des référentiels pouvaient occasionnellement pullobtenir des mises à jour ou de nouvelles fonctionnalités pour leurs sous-modules. Les utilisateurs de ce référentiel auraient alors besoin de mises à jour plus volumineuses que le code du référentiel lui-même.
Carl G

@Carl G: Si vous lisez toutes les réponses ici, vous découvrirez un grand nombre de raisons pour lesquelles les utilisateurs ont choisi Perforce plutôt que git, ce qui n'a rien à voir avec les capacités de git autour des référentiels ou des sous-modules.
Bob Murphy

J'essayais de parler du "temps nécessaire pour peupler initialement un arbre source", mais je constate en réalité que le problème de sous-module que j'ai mentionné est sans importance, car les sous-modules contiennent également tous les historiques de ces référentiels. Je suppose que la seule façon de réduire l’histoire serait d’utiliser des fichiers binaires des dépendances.
Carl G

Eh bien, avec git, vous pouvez créer un clone peu profond et obtenir une petite quantité d’historique, ou peut-être uniquement les fichiers les plus récents (git clone - profondeur 1). Cela fonctionne aussi pour les sous-modules git.
Sahil Singh

38

GIT en particulier, et SVN dans une certaine mesure, n’est pas si vieux - si vous aviez besoin d’un contrôle de version solide au milieu des années 90, vous deviez presque vous lancer dans la commercialisation, car SVN en était à ses balbutiements et CVS était bien CVS. Une fois que vous avez beaucoup investi dans un système, le déplacer peut être un ours.

Oh, et les personnes qui prennent ces décisions n'interagissent probablement jamais avec le système de contrôle de version, mais se font bousculer par le personnel des ventes susmentionné.


4
+1 Nous sommes passés à git relativement récemment et avons dû fonctionner forcément pendant assez longtemps, simplement parce que tout le reste était inférieur.
9000

11
Bien que IMO Perforce me fasse perdre beaucoup de temps. Nous l'utilisons toujours au travail parce que nous avons investi du temps dans le développement d'outils personnalisés qui interagissent avec lui. Pour basculer, il faudrait reconstruire ces outils.
m4tt1mus

2
Perforce et des développeurs ignorants m'ont fait détester vérifier le code. Je préfère écrire du code avec crayon et compiler que .
Jim Schubert

Je pense que vous devriez jeter un oeil sur forcé avant de commenter.
Toby Allen

30

Je suis programmeur dans l'industrie du jeu vidéo depuis presque 9 ans maintenant, et chaque projet sur lequel j'ai jamais travaillé a utilisé Perforce. Je soupçonne que Perforce est toujours utilisé dans ce secteur.

  • Les gens utilisent Perforce depuis longtemps et le maîtrisent assez bien, ce qui les rend hésitants à passer à une autre solution. Les décideurs peuvent également hésiter à confier leur projet de 30 millions de dollars à un logiciel qu’ils n’ont jamais utilisé auparavant.
  • De nombreuses entreprises / équipes ont ajouté le support Perforce à leurs outils internes, ce qui peut nécessiter beaucoup de travail de mise à jour pour prendre en charge un autre VCS.
  • Bien que les programmeurs puissent facilement basculer vers un autre Git / Hg / SVN, il existe de nombreux membres moins techniques dans une équipe de développement de jeux, tels que des artistes, des concepteurs et des producteurs. Les familiariser avec le nouveau système risque de prendre beaucoup de temps, et je serais prêt à parier qu'ils seraient très réticents au changement.

19
Je pense que les "vieux" développeurs (+10 ans) sont probablement aussi résistants au changement que les personnes "non techniques".
Wayne Werner

3
+1 sur ceci, spécifiquement pour cette industrie. Les programmeurs de jeux vidéo ont tendance à avoir tellement de problèmes que changer l'infrastructure avec laquelle ils travaillent est une proposition effrayante. "Si ce n'est pas cassé ..." est un mantra et empêche souvent l'industrie de passer des solutions plus anciennes, même si elles sont plus appropriées.
Chris Subagio

2
@Wayne - commentaire totalement âgiste. J'ai plus de soixante ans et je suis le principal promoteur du changement et de l'innovation dans mon site intermédiaire. James Gosling avait 46 ans lorsqu'il a commencé à écrire la première machine virtuelle Java. Ken Thomson avait 49 ans lorsqu'il a proposé le schéma de codage UTF-8 et 63 ans quand il a commencé à travailler sur le langage GO.
James Anderson

1
@JamesAnderson Je pense que vous êtes probablement sur place. Et si votre organisation n’a pas de culture de l’amélioration, alors vous constaterez l’ effet Mer Morte . Je me demande s'il est possible de changer le système dans son ensemble ou si nous ne pouvons que manipuler notre petite partie de celui-ci.
Wayne Werner

2
@ MikeO'Connor Vous avez également oublié de dire que les jeux utilisent beaucoup d'actifs binaires. Pouvoir verrouiller exclusivement les ressources binaires est un énorme avantage.
CodingMadeEasy

22

Peut-être qu'ils aiment peut-être Perforce parce que Perforce est meilleur?

  • Perforce est rapide. Beaucoup plus rapide que Subversion ou Git.
  • La fusion forcée est meilleure que Subversion ou Git. Git ne fusionne pas vraiment et le suivi de version de Subversion n'est pas très bon, du moins dans la version 1.5.
  • Perforce dispose d'un excellent support client.
  • Perforce combine la révision de référentiel de Subversion avec les révisions de fichiers individuels. Perforce vous permet d'afficher les révisions du référentiel via des listes de modifications ou des révisions de fichiers individuels.
  • Perforce fait beaucoup mieux avec plusieurs listes de modifications que Subversion. Les listes de modifications de Subversion sont en quelque sorte une réflexion après coup et je connais peu d’utilisateurs. Perforce est intégré. Si vous déplacez un fichier modifié de la liste de modifications par défaut, il ne sera pas validé par accident.
  • Perforce vous permet de spécifier la disposition de votre répertoire de travail. Par exemple, si vous avez une arborescence de répertoire de code source standard, mais que certains clients ont une source personnalisée, vous pouvez superposer la source personnalisée sur l'arborescence standard. Vous pouvez facilement effectuer des achats clairsemés en spécifiant uniquement les éléments que vous souhaitez effectuer.

D'accord, avant de penser que je suis un Perforce Fanboi, la dernière fois que j'ai recommandé Perforce à une entreprise, c'était il y a plus de sept ans. Perforce coûte 800 dollars par licence, ce qui est peu coûteux par rapport à ClearCase, mais beaucoup plus cher par rapport à Subversion. J'ai du mal à justifier Perforce plutôt que Subversion.

De plus, la plupart des développeurs sont habitués à Subversion. Ils ne veulent pas apprendre Perforce, qui a une façon de travailler différente de Subversion. Dans Perforce, vous devez créer un client et marquer les fichiers à modifier avant de pouvoir les modifier. Vous n'avez pas à faire cela avec Subversion.

Il y a également moins d'intégrations avec Perforce que Subversion. Cela est en partie dû à l'utilisation du client . Cela ne fonctionne tout simplement pas bien avec VisualStudio ou même Hudson. Cela est dû en partie au fait que Perforce doit créer les intégrations client.

Il y a un coût à la licence propriétaire appeler les coûts administratifs. Imaginez si vous pouviez obtenir une licence pour un logiciel à 1,00 USD par utilisateur. Heck, faisons en deux bits. Des milliers de licences ne vous coûteraient que 250 dollars.

Maintenant, vous avez besoin d'une personne à temps plein pour gérer la licence. Un ouvrier technique moyen reste dans une entreprise pendant environ deux ans. Cela signifie que 500 personnes partiront chaque année et que 500 autres viendront. La licence doit être changée chaque semaine par dix personnes. Ensuite, il y a des moments où le projet démarre et où vous avez besoin de 250 licences supplémentaires. Ceux-ci doivent être commandés, entrés et maintenus. Cela peut prendre des semaines.

C'est pourquoi de nombreuses entreprises commerciales ont opté pour l'open source. Ce n'est pas le coût d'une licence. Vous payez 150 000 dollars par an à un développeur, mais 800 dollars de plus pour une licence Perforce? C'est gérer cette licence. Perforce est bien comparé à ClearCase: plus rapide, plus facile, moins cher, mieux. Mais contre Subversion? Perforce pourrait être plus rapide et peut-être mieux, mais est-ce 800 $ mieux? Gère-t-il mieux la licence? N'est-ce pas mieux d'utiliser un outil souhaité?

C'est pourquoi Perforce peut avoir des problèmes.

Git n'est pas l'outil ultime. Cela fonctionne très bien dans les cas où vous ne voulez pas de contrôle centralisé des personnes ayant accès à un référentiel. Mais, cela peut être une douleur dans de nombreuses circonstances. La façon dont je le dis est la suivante:

  1. Vous exécutez un projet open source. Seriez-vous heureux ou contrarié si un million de personnes possédaient une copie complète de votre référentiel?
  2. Vous exploitez une table de négociation financière qui utilise un logiciel propriétaire pour avoir un avantage sur vos concurrents. Seriez-vous heureux ou contrarié si un million de personnes possédaient une copie complète de votre référentiel?

Si vous effectuez des générations centralisées, vous devez de toute façon utiliser un seul référentiel. Quel est l'avantage d'un système distribué dans cette situation? En fait, cela peut encourager les gens à travailler hors ligne . Les développeurs peuvent simplement partir à leur guise et ne rien commettre avant la dernière minute. Ensuite, vous passez deux jours frénétiques à essayer de tout remettre en marche.

Je ne suis pas contre Git. J'ai recommandé Git dans de nombreux cas. Celles-ci incluent des équipes distribuées ayant de mauvaises connexions les unes aux autres ou des endroits où vous ne souhaitez pas suivre toutes les personnes ayant accès au référentiel source.

Par exemple, un département d'informatique d'un collège souhaitait que ses étudiants utilisent le contrôle de source et y placent leur code pour que les enseignants puissent l'examiner. Bonne idée. Trop d'enfants quittent l'université sans comprendre les procédures standard de construction et de développement. J'ai recommandé Git.

En utilisant Git, l'administrateur du référentiel n'a qu'à prendre des commits de ses collègues professeurs. Ils n'ont pas à s'inquiéter des étudiants individuels. Les professeurs peuvent permettre aux étudiants de s’engager sur leur version du référentiel. Les étudiants peuvent travailler en groupes et chaque groupe peut partager sa version du référentiel.

Si l'université utilisait Subversion, quelqu'un devrait connaître tous les étudiants et leur donner tous accès au référentiel central. Ils devraient gérer qui peut vérifier quoi et où. Si un professeur attribue un projet de groupe, celui-ci devra être configuré et géré. Il vous faudrait une personne à temps plein pour gérer cela.

Ce n'est pas un match de football où une équipe est meilleure qu'une autre. Les outils fonctionnent de différentes manières et chacun a ses avantages et ses inconvénients. Perforce est un excellent outil. Malheureusement, les circonstances sont devenues difficiles à recommander.

Git est génial, mais je continue de faire appel à Subversion pour mon référentiel source personnel. Après tout, je ne le partage pas et Subversion est simplement plus facile à utiliser. J'utilise Git pour le travail personnel si j'ai une petite équipe, car je n'ai pas besoin de garder mon référentiel actif à plein temps sur Internet. Pour la plupart des sites commerciaux, je trouve toujours que Subversion fonctionne le mieux. Mais, il y a des circonstances où Git brille.


40
Attends quoi? Vous m'avez perdu ici "La fusion forcée est meilleure que Subversion ou Git. Git ne fusionne pas vraiment [...]". Pouvez-vous expliquer celui-là?
Sverre Rabbelier

1
En fait, je trouve que Git est plutôt bon pour les fusions, plus agréable que les outils de scm old-school, mais quand dans svn il me manque de pouvoir mettre des choses dans une liste de modifications "ne pas enregistrer" comme je le faisais souvent avec Perforce. (J'ai essayé de le faire dans SVN, mais je finis toujours par vérifier par erreur parce que les listes de modifications svn et p4 se comportent différemment).
JasonTrue

12
@SverreRabbelier 3 ans plus tard, il y a encore des gens qui attendent une réponse à votre question.
Navin

1
"Parce que Perforce est meilleur" ... "Ce n'est pas un match de football où une équipe est meilleure qu'une autre". ...
RJFalconer

4
forcément c'est rapide. beaucoup plus rapide que svn ou git. --- points de repère, ou cela ne s'est pas passé ...; p
sjas

14

Je ne sais pas si la corruption «wine and dine» est toujours applicable, mais pour la plupart des gestionnaires, lorsqu'ils décident de trouver un produit, ils la liront dans diverses publications (destinée à la direction) et consulteront les brochures et dépliants vantant le produit. les vertus.

Devinez quoi, les produits FOSS ne figurent pas dans ces endroits!

Il est donc presque évident que la plupart des décisions d’achat de la direction sont dictées par la publicité et le marketing. Ils peuvent effectuer des évaluations, mais de plusieurs de ces produits.

L'autre raison est due à l'échéance. Certains produits que nous utilisons aujourd'hui ne sont assez stables que depuis peu pour une utilisation professionnelle sérieuse, certains n'ont pas d'options de support, d'autres n'ont pas fait leurs preuves en tant que solutions commerciales. Ce sont des éléments importants à prendre en compte (bien que, en tant que technicien, j’évaluerai volontiers les solutions FOSS si le risque de les utiliser et de les empêcher de les utiliser est minime pour le bon fonctionnement de l’entreprise) et certains gestionnaires craignent à juste titre de ne pas les avoir. Ils sont responsables devant leurs patrons et se sentiront beaucoup plus à l'aise s'il existe une organisation de soutien derrière le produit - vous en avez une pour votre entreprise, après tout.

Enfin, bien que de nombreux produits FOSS aient un support derrière eux (pensez à Collabnet ou à Wandisco pour SVN), ils ont tout de même la réputation de 'made by geeks in leur back bedroom'. Nous savons tous que c'est généralement b * * ** t et que le meilleur FOSS rivalise incroyablement bien avec les offres commerciales, mais mon responsable doit encore être convaincu. peut-être n’at-il pas conscience de la différence entre les produits FOSS immatures et matures; peut-être qu'il s'en fiche.

Quoi qu'il en soit, Perforce est un bon SCM, il n'y a aucune raison de ne pas le choisir. Je pourrais dire la même chose pour les autres SCM, mais là encore, je ne peux que dire du mal de certains autres, et faire encore des cauchemars en ce qui concerne certains produits.


Cet argument était plus convaincant il y a une décennie, mais de nombreux produits FOSS sont aujourd'hui largement utilisés. y compris SVN, qui est utilisé dans certaines grandes entreprises.
Jeremy

Peu m'importe que les logiciels libres aient le droit de concurrencer - je tiens à ce que mon responsable pense que non. En outre, certaines grandes entreprises évoluent lentement, de sorte qu'elles y parviennent encore. Il faudra encore quelques années à certaines d'entre elles pour évaluer les produits FOSS.
gbjbaanb

gbjbaanb Vous me comprenez mal. Je ne pense pas que les facteurs que vous décrivez soient presque aussi pertinents à quelque niveau de la direction qu’il l’était il ya 10 ans. Même si cela pourrait être votre cas, il serait erroné de le généraliser. Le logiciel libre est standard, ce qui signifie qu'il est adopté par la plupart des grandes entreprises et utilisé dans les systèmes centraux.
Jeremy

6
Je pense que ceci est un point clé: les outils FOSS ne se font pas de publicité, vraiment parce qu’ils n’ont aucune raison de le faire. Les brochures et les éléments que vous mentionnez font partie de ce travail, mais même si je fais référence aux "systèmes de comparaison SCM" ou au "système de contrôle des versions de comparaison" de Google, les seules choses que je trouve sont celles de Perforce. Bien sûr, je dois prendre en compte la source, mais je ne connais pas les outils FOSS prenant des efforts pour se faire connaître et pour expliquer pourquoi ils sont les meilleurs. Je sais que nous méprisons le commercialisme, mais parfois, le marketing et la publicité m'aident réellement à faire un choix éclairé.
Chance

1
Je pense qu'il y a deux excellentes raisons de ne pas choisir Perforce: 1. Le branchement coûte très cher, et 2. Le processus de vérification puis de modification rend le travail hors connexion très difficile à réconcilier.
Kevin Cline

14

Parce que des outils comme Perforce ont des vendeurs de vin et des personnes en charge des achats, contrairement à Git. Bien sûr, ce n’est que mon côté cynique quand je parle, mais c’est un cynisme provoqué par le fait de voir le processus de plus près.

Soyons clairs: je ne veux pas dire que chaque fois que vous voyez votre DSI sombrer dans l’ivresse dans le couloir, attendez-vous à utiliser un nouveau système de gestion des versions le trimestre prochain. Il existe simplement un décalage entre l'utilisation et l'acquisition dans de nombreuses organisations. Bien entendu, les entreprises utilisent Perforce pour d'autres raisons: par exemple, elles ont peut-être déjà beaucoup investi dans sa mise en œuvre dans leur flux de travail. Mais généralement - et cette question est très générale - il n’ya aucun avantage fonctionnel à ne pas utiliser les outils FOSS.


13
Cela peut sembler cynique, mais en gros, vous avez touché le bout des doigts. Dans ma propre entreprise, je m'efforce de promouvoir les solutions FOSS, car les membres de l'exécutif ont l'impression que si c'est gratuit, cela ne peut pas être bon.
Wolfgangsz

1
amen à cela, même si je les aurais peut-être un peu transformés quand ils ont remplacé notre solution SVN par une solution "d'entreprise" qui coûtait une fortune, des consultants, deux sous-traitants pour l'administrer, et après beaucoup de lamentations, grincements de dents, opération de buggy et la mort de notre productivité ... a été jetée et remplacée par notre ancienne solution SVN.
gbjbaanb

7
Google n'est pas vraiment connu pour ce type de culture.
Jeremy

11
@Chance: Pour quelle sorte de choses contactez-vous le support technique? J'ai utilisé CVS, Subversion et Mercurial, et je ne me suis jamais retrouvé à souhaiter pouvoir appeler quelqu'un. Si j'ai un problème, je google, ou je poste une question, et le problème est résolu, généralement en quelques minutes. Je suggérerais qu'un outil de contrôle de source qui nécessite l' assistance du développeur du système pose un problème sérieux.
Tom Anderson

2
@TobyAllen: pas avant six ans environ (notez la date de la question) mais ces jours-ci, il semble que même Perforce veuille utiliser autre chose que Perforce: perforce.com/git
Dmitri

12

Probablement la même raison pour laquelle mon entreprise refuse d’utiliser beaucoup de logiciels open source (même si je ne suis pas d’accord):

Quand quelque chose ne va pas, ils veulent quelqu'un à qui ils peuvent appeler et crier dessus.


2
Je suis d’accord: c’est une raison importante pour de nombreux services informatiques, mais cela semble immature. "Ce n'est pas notre faute, c'est LEUR FAUTE". Choisir un produit de qualité inférieure simplement à cause du potentiel de pointer du doigt "du cou pour tordre" semble être une décision infantile. Non pas que cela ne soit pas souvent fait, mais que cela semble bébé.
Bruce Ediger

Votre réponse ne fait pas référence au support technique de Perforce. Dommage, car si vous saviez à quel point c'était bon, votre réponse n'aurait peut-être pas été donnée. Le support technique Perforce est stellaire et engagé, et les problèmes sont résolus rapidement.
Br.Bill

9

Alors que toutes les réponses parlent de grandes entreprises utilisant P4 (et elles expliquent pourquoi Google a utilisé P4), l'une des principales raisons pour lesquelles Google continue d'utiliser Perforce est que Perforce vous permet d'extraire un sous-arbre du rapport alors que vous ne pouvez pas le faire avec Git. Avec des dépôts à source importante comme Google, cela a fait une énorme différence.

Et autant que j'ai entendu, Facebook utilise SVN et Git-SVN


1
Absolument, les sous-propositions encouragent et facilitent la réutilisation du code. C’est la raison pour laquelle je choisis Perforce lorsque j’ai mon mot à dire. Grosse affaire! Mélangez et faites correspondre facilement le code provenant de différentes pensions (la sous-déclaration de hg), en suivant qui utilise une sous-déclaration particulière, et en étant capable de suivre facilement les archivages, les branches et les fusions de toutes les pensions. Tout en simplifiant les choses pour le développeur final avec une spécification de client à ligne unique et en conservant les détails dans la spécification de branche pour les super-utilisateurs. À l'heure actuelle, je suis obligé d'utiliser Mercurial dans le cadre d'un projet de grande envergure et traiter avec des sup-repo avec du mercure coûte beaucoup d'argent en perte de productivité.
stephenmm

8

Parce que SVN est bien, SVN, et Perforce (il y a quatre ans, quand on comparait des outils) fait mieux que SVN . (Je pense que ramifier est l'un d'entre eux.)

Et GIT est un DVD, comme dans distribué . Pour les équipes de la société, la partie distribuée pourrait bien être quelque chose que ni les soins ni les désirs ne visent.


5
Vous pouvez utiliser parfaitement Git avec différents workflows. La distribution n’est donc pas un problème… à moins que l’équipe de la société n’ait aucune idée de ce qu’elle était. whygitisbetterthanx.com/#any-workflow
M. Dudley Le

2
Je ne dirais pas que Perforce fait bien la ramification ... la création de branches Perforce donne une copie occupée de tout ce qui est ramifié. SVN se branche par copie paresseuse, ce qui le rend beaucoup plus rapide.
Kevin Cline

1
@Jason - la création de branches sur la subversion se produit plus rapidement que je ne saurais taper: "svn cp ...; svn switch ..." La création de branches est forcément extrêmement complexe; créer une spécification de branche, créer un espace de travail, intégrer, commettre. Zut, avec forcément c'est tout comme ça. Sans branchement rapide et facile, je considère qu'un RCS est essentiellement inutilisable. À en juger par le trafic net et la rapidité de l’amélioration, il semblerait que Perforce soit un produit en fin de vie.
Kevin Cline

1
@ Kevin, je ne sais pas comment vous allez créer des branches, mais je ne fais que la partie intégration, validation. Je n'ai jamais défini la spécification de branche et je n'ai jamais eu à créer un espace de travail pour créer une branche (bien que j'aie peut-être dû modifier le mappage de mes vues si j'ai décidé d'exclure des répertoires dans ma vue). Cela étant dit, je n'ai rien fait avec svn, je ne peux donc pas commenter cet aspect.
Chance

1
@ kevin: Vous savez si quelque chose "fonctionne mieux" n'est pas nécessairement fonction du nombre de commandes CLI nécessaires pour le faire. Juste un commentaire de quelqu'un qui ne maîtrise pas très bien SVN ni Perforce.
Martin Ba

6

Une autre raison pour laquelle les grandes entreprises ont tendance à acheter de gros systèmes de contrôle de version "entreprise":

Dans les départements informatiques, les cadres moyens et supérieurs considèrent VCS comme un outil que chaque projet utilise, ou que vous pouvez imposer son utilisation. Une fois que vous avez imposé l’utilisation d’un VCS, pourquoi ne pas y inclure également un petit "processus"? Je veux dire, vous avez la possibilité de spécifier un système "à l'échelle de l'entreprise", pourquoi ne pas l'obtenir sous contrôle central, et ajouter "reprise après sinistre" et quelques "fonctionnalités de flux de travail" afin que vous puissiez dire "Nous sommes au niveau CMM conforme! ". Un VCS est simplement une cible trop facile à intégrer pour mettre en œuvre des fonctionnalités d’application du flux de travail.

En ce qui concerne le choix de certains logiciels croustillants et crasseux (Serena Dimensions), il est dit que quelques manches de Bikini Golf aux Bahamas avec une vingtaine de membres du personnel de vente peuvent convaincre un directeur ou un vice-président de n'importe quoi.


aucun commentaire, mais je veux savoir lequel de nos sous-traitants ou de nos gestionnaires a eu l'occasion de jouer au bikini golf!
gbjbaanb

5
Je l'admets, Bikini Golf travaillerait probablement sur moi aussi.
Jhocking

5

Les grandes entreprises ont besoin d’un modèle centralisé. Une fois que les développeurs ont terminé leur développement, il est transféré au support client. Voulez-vous vraiment être dans la peau du support quand ils doivent passer au peigne fin dans les dépôts de développeurs distribués 50-200? Et les builds sont basés sur le référentiel central. Les builds doivent toujours, toujours, toujours être traçables et reproductibles. Vous apprenez cela la première fois que vous êtes poursuivi en justice pour violation stupide de brevet.

Git ne fonctionne pas aussi bien dans ce modèle. Si vous avez une petite entreprise ou une entreprise avec un accès VPN faible, c'est là que ça brille vraiment.


2
La définition du flux de travail, qu'il soit centralisé ou décentralisé, n'a pas d'importance. Le travail de support n’est pas plus facile lorsque vous essayez de parcourir 200 branches dans le référentiel central. Dans l'ensemble, les entreprises choisissent des solutions centralisées parce que c'est ce avec quoi elles se sentent à l'aise. Il n'y a aucun avantage appréciable par rapport à un DVCS utilisé avec un référentiel partagé centralisé.
Wadesworld

4

Une des raisons pour lesquelles la plupart des grandes entreprises utilisent Perforce est peut-être qu’il ya plus de professionnels dans le service informatique qui ont beaucoup de connaissances à ce sujet et qui ont des années d’expérience en matière de résolution de problèmes.

Je pense qu'à l'avenir, les entreprises pourraient commencer à s'éloigner de Perforce et plus encore de GIT ... la plupart des développeurs que je connais semblent le préférer !! Consultez également http://whygitisbetterthanx.com/#git-is-fast pour plus de preuves sur les raisons pour lesquelles Perforce pourrait ne pas être aussi dominant dans les années à venir!


4

Il y a quelques temps, nous sommes passés d'un ensemble de VCS (je suis sûr que RCS, CVS, ClearCase, Perforce étaient utilisés auparavant, il pourrait en exister d'autres) à Perforce en tant que système unique utilisé. Ce n'était pas un petit projet: la migration a pris plus d'un an. L'équipe en charge (je n'en faisais pas partie) a évalué plusieurs VCS, et au moins git et svn ont été pris en compte, ainsi que ceux déjà utilisés. Si je me souviens de leur rapport, ils ont filtré les outils sans les fonctionnalités nécessaires et ont ensuite pris en compte:

  • performances sur utilisation typique, en particulier pour les sites distants

  • besoins en ressources

  • importance des changements nécessaires dans l'habitude de travail

  • support et disponibilité

et Perforce était un gagnant assez clair dans l'ensemble. git était légèrement meilleur pour le premier point, mais désavantageux pour les autres.


3

Il était une fois, il n'y a pas si longtemps (lorsque l'EDI s'appelait VI), les seuls systèmes libres (open source) étaient CVS, RCS et SCCS.

  • Aucun de ceux-ci ne pourrait même gérer un fichier renommé.
  • Ils n’enregistraient pas les fusions. Par conséquent, si deux branches étaient en activité, il était très difficile de les fusionner jusqu’à la fin des travaux sur une branche.
  • Ils n'ont pas bien évolué vers de très grandes bases de code
  • Ils ne fournissaient pas le niveau de contrôle d'accès et d'informateur requis par les grands projets.

Il existait de nombreux systèmes de contrôle de code source commerciaux, la plupart d'entre eux étant fournis par un seul fournisseur de machines (IBM, DEC, HP, etc.) et fonctionnant uniquement sur leur matériel.

Ensuite, quelques sociétés ont déclaré vendre le contrôle de code source commercial multiplate-forme, notamment Perforce et ClearCase.

ClearCase a été construit sur RPC qui ne fonctionnait pas bien sur les réseaux étendus (Internet seul cependant) en raison de nombreux «petits paquets réseau» «trébuchés», IBM et rational ont également vu ClearCase comme une «vache à lait» et ne l'ont jamais beaucoup montré. l'amour.

Ainsi, le seul «ancien» système de contrôle de code source commercial encore utilisé couramment est Perforce. Une fois que perforce est effectivement utilisé et intégré dans les systèmes de construction et les systèmes de suivi des bogues, il n’ya que très peu d’ avantages à court terme pour une entreprise de passer à autre chose.

Donc, pour résumer, nous avons forcément eu le "pied dans la porte" quand il n'y avait pas beaucoup d'autres options, et ils n'ont pas encore suffisamment gâché pour inciter les gens à s'en sortir .

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.