Résumé
- Perforce doit être jugé sur sa capacité à amener de grandes modifications de code source, d'actifs de jeu et de conception matérielle dans un état accepté fiable, et non sur des déclarations générales concernant la seule échelle des dépôts.
- Le cas le plus solide pour P4 concerne les équipes où les actifs binaires, les verrous exclusifs, les listes de modifications (changelists), les streams, les revues, les autorisations, l'intégration de build et la rigueur de récupération réduisent le coût de coordination quotidien.
- Le risque commercial est que Perforce puisse remplacer les difficultés de fusion de Git par des coûts de licence, une administration spécialisée, des frictions de migration, une planification du stockage et un enfermement propriétaire, à moins que l'acheteur ne mesure la charge d'exploitation complète.
- La documentation publique et les témoignages de clients appuient la thèse du changement accepté, mais aucun test pratique de dépôt n'a été réalisé pour cet article; les performances, le support et l'économie propre à l'acheteur restent donc conditionnels.
Le changement accepté est l'unité qui compte
La question pratique concernant Perforce n'est pas de savoir si un dépôt peut contenir une grande quantité de contenu. Un dépôt peut être immense et pourtant mal géré. Un dépôt de jeu peut contenir des téraoctets d'art tout en laissant des artistes attendre des verrous, des designers incertains de la révision de carte en cours, des programmeurs aux prises avec des branches d'intégration périmées et des équipes de build reconstruisant du travail qui aurait dû être rejeté avant soumission.
Un dépôt de semi-conducteurs peut contenir des millions de fichiers et échouer dès qu'un bloc IP, un artefact de simulation ou un fichier de contraintes est déplacé sans traçabilité vérifiable. La question difficile est plus étroite: une équipe peut-elle prendre un changement proposé et le faire accepter de manière à ce que d'autres puissent lui faire confiance?
Cet état accepté comporte plusieurs aspects. Les fichiers modifiés doivent être les bons fichiers, avec le bon type de fichier, sous les bons contrôles d'accès. Le changement doit être associé à une description significative, une revue, un problème ou un résultat de build, plutôt que de disparaître dans un tas de modifications sans rapport. Les fichiers binaires ne doivent pas être écrasés silencieusement par une modification parallèle qui ne peut pas être fusionnée. Les synchronisations de grands espaces de travail doivent être suffisamment prévisibles pour que les contributeurs n'aient pas peur de récupérer le dernier état.
Les règles de branches ou de streams doivent être suffisamment lisibles pour que les gens sachent où un changement appartient. Si le changement s'avère mauvais, l'équipe doit pouvoir le retrouver, l'annuler, restaurer l'état précédent ou expliquer pourquoi l'annulation est dangereuse.
La gamme de produits P4 de Perforce est construite autour de ce type de gestion d'état. Le serveur conserve un enregistrement central des fichiers et des métadonnées. Les listes de modifications fournissent une unité de travail de type transaction. Le verrouillage de fichiers peut empêcher un autre utilisateur de soumettre des modifications conflictuelles sur des fichiers sélectionnés. Les streams offrent aux équipes un modèle de branchement contrôlé. P4V donne aux utilisateurs non familiarisés avec la ligne de commande un client visuel. P4 Code Review, anciennement Helix Swarm, relie les revues aux listes de modifications P4.
P4 DAM offre aux artistes et autres utilisateurs de contenu une interface web pour trouver, réviser et réutiliser des actifs. L'intérêt de ces produits n'est pas seulement de garder un dépôt plein. L'intérêt est de rendre le prochain changement accepté moins ambigu.
C'est pourquoi Perforce reste commercialement pertinent même dans un monde logiciel dominé par Git. Git est excellent pour de nombreuses équipes axées sur le code. Le branchement distribué, les commits locaux peu coûteux, le large écosystème et la collaboration cloud en font le point de départ par défaut pour la plupart des développements modernes. Mais les forces de Git peuvent devenir des coûts d'exploitation lorsque le projet est rempli de binaires non fusionnables, de gros actifs générés, de besoins d'audit hautement réglementés ou de dépendances de build centralisées.
Git Large File Storage, les contrôles d'hébergement Git, les magasins d'artefacts et les systèmes d'actifs numériques peuvent répondre à une partie de ce problème. Ils ne créent pas toujours un état accepté unique que les artistes, les ingénieurs, les gestionnaires de build et les réviseurs de conformité expérimentent de la même manière.
L'article traite donc Perforce comme un système de contrôle des changements de dépôt acceptés. L'échelle du dépôt compte, mais seulement en tant que charge placée sur ce système de contrôle. Un acheteur ne devrait pas demander: « Perforce peut-il stocker nos fichiers? » Il devrait demander: « Perforce peut-il rendre le prochain changement accepté moins cher, plus clair, plus sûr et plus récupérable que notre mélange actuel de Git, stockage cloud, partages de fichiers, bases de données d'actifs et scripts de build? »
L'état centralisé n'est un avantage que lorsque l'équipe a besoin d'une vérité partagée
La conception centralisée de P4 est souvent présentée en contraste avec le modèle distribué de Git. Ce contraste est réel, mais il n'est automatiquement ni bon ni mauvais. L'état centralisé est précieux lorsque le coût du désaccord est élevé. Un grand studio ne veut pas que deux artistes d'environnement soumettent sans le savoir des versions incompatibles d'un actif de scène lourd. Une équipe de conception matérielle ne veut pas qu'un ingénieur utilise une vue périmée des fichiers de conception associés alors qu'un autre groupe a déjà déplacé la révision de contrôle.
Une équipe logicielle réglementée ne veut pas que les preuves de version soient dispersées dans des historiques locaux, des partages d'artefacts non documentés et des commentaires de tickets qui ne correspondent que partiellement au code livré.
Dans ces situations, l'état central peut réduire l'incertitude. Le serveur sait quelle révision est la tête, quels fichiers sont ouverts, quels verrous sont actifs, quelle liste de modifications a été soumise, quel utilisateur et quel espace de travail l'ont soumise, quel stream elle a affecté et quelles autorisations s'appliquaient. Cela ne rend pas le processus bon en soi. Un serveur central peut devenir un goulot d'étranglement. Il peut être mal configuré. Il peut tomber en panne. Il peut forcer trop de trafic par un chemin lent. Mais lorsque l'équipe a besoin d'une réponse partagée à « qu'est-ce qui est accepté maintenant?
», la centralisation donne à Perforce un endroit naturel pour attacher la revue, le build, les autorisations, les verrous et la récupération.
L'optique du changement accepté explique aussi pourquoi Perforce est souvent plus fort en dehors du travail purement code. Les fichiers source peuvent généralement être fusionnés car le format texte expose la structure. Les fichiers binaires ne le peuvent généralement pas. Même lorsqu'un outil peut produire un diff pour un format binaire ou semi-binaire, la fusion peut être sémantiquement dangereuse. Une texture, un niveau, une exportation CAO, un résultat de simulation ou un actif compilé peut n'avoir de sens que dans son ensemble. Pour ces fichiers, un verrou n'est pas un échec de la collaboration moderne.
C'est un signal qu'une modification parallèle gaspillerait du travail.
Le marketing de Perforce met beaucoup l'accent sur le code source, les actifs 3D, l'échelle, le verrouillage de fichiers, les streams, les serveurs proxy et edge, les journaux d'audit, les intégrations et l'utilisation industrielle dans les jeux, les semi-conducteurs et l'automobile. La version crédible de cette histoire n'est pas que chaque équipe devrait tout centraliser. C'est que certaines équipes se comportent déjà comme si elles avaient besoin d'une vérité centralisée, mais elles l'ont mal assemblée à partir de plusieurs systèmes.
Elles gardent le code dans Git, l'art dans des drives cloud, les sorties de build ailleurs, les paquets de conception dans des dossiers partagés et les preuves de version dans des tickets. La taxe d'intégration apparaît alors au moment de l'acceptation: personne n'est sûr que l'actif dans le build correspond à l'actif révisé, que le binaire dans le magasin d'artefacts a été verrouillé avant la mise à jour, que le ticket a été fermé par la bonne révision ou que le retour en arrière signifie annuler un changement, restaurer un dossier ou reconstruire un environnement de mémoire.
Perforce gagne sa place lorsque l'état central n'est pas seulement une préférence mais une surface de contrôle. Si le dépôt partagé est la source de vérité pour le code, le contenu et les métadonnées associées, l'équipe peut attacher une cérémonie d'acceptation cohérente au changement. Si une équipe édite principalement du code texte, a de petits dépôts, s'appuie sur les contrôles Git natifs du cloud et peut reconstruire proprement les artefacts à partir des sources, la centralisation peut ajouter plus de poids que de valeur.
La décision devrait commencer par le coût du désaccord, et non par une préférence générique pour le contrôle de version centralisé ou distribué.
Les listes de modifications rendent l'acceptation explicite, mais elles ne garantissent pas la qualité
La liste de modifications est l'une des idées les plus importantes de Perforce car elle transforme un changement proposé en un paquet nommé. La documentation de Perforce décrit les listes de modifications soumises et en attente comme l'unité de travail versionné. Une liste de modifications peut inclure des fichiers, des descriptions, des tickets et des métadonnées. L'opération de soumission est décrite comme atomique: soit tous les fichiers listés dans la liste de modifications sont enregistrés dans le dépôt, soit aucun ne l'est. Cela importe car l'acceptation n'est pas un état philosophique.
C'est une transition du travail dans un espace de travail client vers l'historique du dépôt stocké.
L'atomicité est utile car les équipes ont besoin que les changements voyagent ensemble. Un correctif de code peut nécessiter un ajustement de script de build et une mise à jour de données de test. Un changement d'actif de jeu peut nécessiter une texture, un matériau, un fichier de scène et un fichier de métadonnées. Un changement de conception matérielle peut nécessiter des fichiers de conception et des contraintes associés. Si ces éléments entrent séparément dans l'état accepté, les utilisateurs en aval peuvent brièvement voir un projet incohérent. S'ils entrent ensemble, la revue et la récupération peuvent s'attacher à une unité cohérente.
Mais une liste de modifications n'est pas une garantie de qualité. Elle peut être trop grande. Elle peut mélanger des modifications sans rapport. Elle peut porter une description vague. Elle peut passer par une revue faible. Elle peut être soumise contre un stream qui rend l'intégration ultérieure coûteuse. Elle peut contenir des fichiers générés qui auraient dû être reconstruits par le pipeline plutôt que versionnés. Elle peut techniquement soumettre tout en étant une mauvaise décision opérationnelle. Perforce aide à définir le paquet; l'acheteur doit encore définir à quoi ressemble un bon paquet.
Le test du changement accepté devrait donc examiner la discipline des listes de modifications. L'équipe garde-t-elle les listes de modifications assez petites pour être révisées? Les actifs binaires sont-ils groupés avec les métadonnées qui les rendent significatifs? Les références de tickets sont-elles obligatoires là où elles importent? Les vérifications de build et de revue sont-elles attachées avant l'acceptation ou après que les dégâts soient déjà entrés dans le dépôt? Les soumissions d'urgence sont-elles distinguées du travail planifié ordinaire?
Les listes de modifications restreintes sont-elles utilisées lorsque des fichiers confidentiels nécessitent une visibilité limitée? Les réviseurs peuvent-ils voir suffisamment d'informations pour comprendre l'impact sans télécharger une archive massive?
P4 Code Review renforce ce modèle en liant les vues de revue aux listes de modifications et aux fichiers. Sa documentation montre qu'elle peut afficher les fichiers modifiés, les métadonnées, les commentaires, l'état de la revue et des diffs pour les fichiers texte et image. Elle expose également une limite importante: les grandes listes de modifications peuvent stresser l'affichage de la revue, et une documentation récente décrit une limite par défaut du nombre de fichiers pour les listes de modifications afin d'éviter des problèmes de mémoire et de navigateur. C'est un avertissement utile.
Un outil peut connecter la revue à une liste de modifications, mais si l'équipe traite des vidages massifs d'actifs comme révisables de la même manière qu'un changement de code de cinq fichiers, l'état accepté devient nominal plutôt que significatif.
L'implication commerciale est simple. Perforce peut rendre l'acceptation explicite. Elle ne peut pas décider par elle-même si l'acceptation est sage. Les acheteurs devraient budgéter non seulement le produit, mais aussi les règles concernant la taille des listes de modifications, les descriptions, la couverture de revue, la vérification de build, la politique de type de fichier et le traitement des exceptions. Si ces règles sont absentes, Perforce peut enregistrer de mauvaises décisions avec une excellente fidélité.
Les actifs binaires transforment le verrouillage en politique de coordination
Le verrouillage de fichiers est facile à caricaturer comme démodé. Les équipes logicielles modernes sont habituées au travail parallèle, aux pull requests et à la résolution des conflits de fusion. Pour le code source texte, cette culture est souvent juste. Les développeurs peuvent travailler sur des branches séparées, fusionner, réviser et résoudre les conflits. Le coût social des conflits occasionnels est compensé par la liberté de travailler indépendamment.
Les actifs binaires changent le calcul. Si deux personnes modifient la même grande texture, le même modèle, niveau, vidéo, artefact matériel ou paquet applicatif, la modification perdante peut ne pas être fusionnable. Le conflit n'est pas un simple hunk de texte. Cela peut signifier un travail répété, des régressions visuelles incertaines, des dépendances corrompues ou un processus d'arbitrage humain où l'équipe décide quelles heures sont perdues. Dans ce contexte, un verrou n'est pas seulement une fonctionnalité technique.
C'est une politique de coordination: avant de passer du temps à éditer ce type de fichier, réservez le droit de le soumettre ou, au minimum, rendez votre travail visible aux autres.
P4 soutient cette politique à plusieurs niveaux. La référence de commande décrit le verrouillage des fichiers ouverts pour empêcher les autres de soumettre des modifications sur ces fichiers, et la libération de ce verrou lorsque le détenteur du verrou soumet. P4V offre aux utilisateurs du client visuel une action de verrouillage optionnelle après l'extraction. Le matériel produit par P4 met l'accent sur le verrouillage exclusif des fichiers comme un moyen d'éviter les collisions.
Les témoignages de clients de Perforce reviennent sans cesse sur ce point dans les contextes de jeux et de médias, où les gros fichiers binaires et les actifs de conception créent un risque de coordination quotidien.
Git a des réponses à ce problème. Git LFS remplace les gros fichiers par des pointeurs et stocke le contenu ailleurs. Les fournisseurs d'hébergement Git proposent des plans LFS, des limites de taille de fichier, du stockage et une facturation de bande passante. GitLab documente le verrouillage de fichiers comme particulièrement précieux pour les fichiers binaires, et le projet Git LFS a depuis longtemps reconnu le verrouillage comme un moyen de décourager les modifications parallèles qui conduisent à des situations non fusionnables. Ce sont de vraies alternatives.
Un acheteur ne devrait pas prétendre que les seuls choix sont « Perforce » et « le chaos ».
La comparaison porte sur l'exhaustivité et l'adéquation opérationnelle. Git LFS préserve un flux de travail centré sur Git mais ajoute la gestion des pointeurs, la dépendance au serveur LFS, les limites de plan, les étapes de migration et parfois des pratiques de verrouillage séparées. La documentation de GitHub indique aussi clairement que les limites de fichiers et de taille des dépôts ordinaires restent une considération de planification, et que LFS a des limites de fichiers basées sur le plan et un comportement de facturation. Pour de nombreuses équipes, c'est acceptable.
Pour certaines équipes, en particulier celles où l'art, le code, les outils et les sorties de build doivent partager une seule surface opérationnelle, l'aspect « ajouté après coup » devient coûteux. Les gens doivent savoir quels fichiers sont dans Git, lesquels sont dans LFS, lesquels sont dans un gestionnaire d'actifs, lesquels sont dans un magasin d'artefacts de version et quel système fait autorité pour le verrouillage.
L'avantage de Perforce est que le verrouillage peut résider dans le même état de dépôt que les listes de modifications, les autorisations, les streams, la revue et la récupération. Son inconvénient est que la contention des verrous devient visible et parfois douloureuse. Si un fichier de niveau crucial est verrouillé par quelqu'un dans un autre fuseau horaire, l'équipe peut bloquer. Si les verrous sont oubliés, l'administration doit les effacer. Si un type de fichier est incorrectement défini comme non exclusif, les modifications parallèles peuvent revenir.
Si les verrous exclusifs doivent voyager à travers une infrastructure d'edge de commit, la propre documentation de Perforce avertit que les verrous exclusifs globaux nécessitent une communication avec le serveur de commit et peuvent entraîner de la latence. Le verrouillage supprime un type de travail de coordination en en créant un autre. Le travail de l'acheteur est de décider quel type est le moins cher.
Le type de fichier et la politique de stockage décident si les gros fichiers restent gérables
La capacité de gérer de gros fichiers est souvent discutée comme s'il s'agissait d'une seule fonctionnalité. En pratique, c'est un ensemble de politiques. Le système doit identifier correctement les fichiers binaires, stocker les révisions de manière consciente des coûts, transférer rapidement les bons fichiers, garder l'état de l'espace de travail compréhensible, protéger le contenu coûteux de l'exposition accidentelle et permettre la récupération lorsqu'un fichier est endommagé ou mal accepté.
Perforce expose une partie de cette politique à travers les types de fichiers et les typemaps. La référence de commande décrit comment les fichiers nouvellement ajoutés sont examinés par rapport à la table typemap, puis par détection binaire si aucune correspondance n'est trouvée. Elle explique également que les révisions binaires sont généralement stockées en entier, avec compression, tandis que le texte a un comportement de stockage différent. La commande typemap permet aux administrateurs de connecter les types de fichiers aux motifs de fichiers du dépôt afin que les fichiers se voient attribuer le type prévu lors de l'ajout.
Cela semble de bas niveau, mais c'est central pour l'état de dépôt accepté. Si un studio de jeux ne parvient pas à classer correctement les fichiers binaires verrouillables au moment de l'ajout, les hypothèses de verrouillage, de stockage et de transfert en aval sont erronées avant même que la revue ne commence.
Le même problème apparaît avec les fichiers générés et dérivés. Certains actifs sont des actifs sources et doivent être versionnés. Certains sont des sorties de build et doivent être reproduits. Certains sont des artefacts coûteux qui doivent être conservés car la reconstruction est impraticable. Certains appartiennent à un registre de paquets ou à un magasin d'objets plutôt qu'au dépôt. Perforce peut contenir de nombreux types de contenu, mais « pouvoir contenir » n'est pas la même chose que « devoir contenir ».
Un acheteur qui déplace tous les caches temporaires, rendus intermédiaires, produits de build locaux et dépendances téléchargées dans P4 peut transformer le dépôt en décharge. L'optique du changement accepté demande si le fichier doit être accepté comme état de projet durable.
L'économie du stockage importe car Perforce est souvent en concurrence non seulement avec Git mais aussi avec le stockage d'objets cloud, les registres d'artefacts et les systèmes de gestion des actifs numériques. Un bucket cloud peut être moins cher pour de grandes archives immuables. Un registre de paquets peut être meilleur pour les produits de build versionnés. Un système d'actifs spécialisé peut être meilleur pour la découverte et l'approbation par les utilisateurs créatifs.
P4 DAM est la réponse de Perforce à une partie de ce problème: il ajoute une couche d'actifs web construite sur P4 pour que les contributeurs puissent trouver, réviser, réutiliser et partager des actifs sans traiter le backend de versionnement comme un outil réservé aux développeurs. Cela renforce Perforce pour les équipes créatives, mais cela renforce aussi la nécessité de concevoir le modèle d'actif. Le dépôt backend ne rend pas à lui seul une bibliothèque visuelle utile.
La gestion des gros binaires nécessite donc une taxonomie d'acceptation en amont. Quelles extensions sont en verrouillage exclusif par défaut? Quels fichiers sont texte, binaires, compressés, générés, fournis par le fournisseur ou critiques pour la version? Quel contenu doit être stocké dans P4, lequel doit être référencé et lequel doit être régénéré? Quels fichiers doivent être visibles par les sous-traitants, les partenaires, les artistes, les ingénieurs et les systèmes de build? Quels fichiers sont si volumineux que la revue doit utiliser des vignettes, des métadonnées ou des aperçus spécifiques à l'outil plutôt que le téléchargement brut?
Ces décisions ne sont pas glamour, mais elles déterminent si Perforce réduit ou augmente la friction.
Les acheteurs les plus solides traitent la politique de type de fichier et de stockage comme de l'ingénierie produit, et non comme de la maintenance de dépôt. Ils écrivent les règles avant la migration, les testent sur des actifs représentatifs et rendent les exceptions visibles. Les acheteurs faibles attendent que le dépôt soit déjà pollué, puis découvrent que le coût du nettoyage est plus élevé que le coût de la planification ne l'aurait été.
Les streams et les revues décident si le contrôle reste utilisable à l'échelle
Le contrôle de version échoue à l'échelle lorsque les gens ne peuvent pas répondre où un changement appartient. Une branche de fonctionnalité, une branche de version, une branche moteur, une branche de contenu ou une ligne de conception matérielle peuvent toutes être légitimes. Le problème n'est pas l'existence des branches; c'est la perte de sens partagé. Les Perforce Streams sont conçues pour donner une structure au branchement et à la gestion des lignes de code source. Le matériel produit présente les streams comme un moyen d'aller au-delà du branchement de base et de mettre en place des cadres reproductibles.
La référence de commande montre également que les spécifications de stream peuvent elles-mêmes être éditées et soumises par le processus de changement habituel.
Cela importe car l'état accepté n'est pas unidimensionnel. Un changement peut être accepté dans un stream de développement mais pas dans un stream de version. Il peut être accepté dans une branche de plateforme mais pas dans une branche de jeu. Il peut être accepté pour un programme de véhicule mais pas pour un autre. Il peut être accepté dans un bac à sable de conception matérielle mais pas dans la ligne de base IP réutilisable. Un acheteur qui adopte Perforce sans discipline de stream peut encore se retrouver avec une carte de branches confuse, seulement maintenant dans un nouveau système.
La question utile est de savoir si les streams réduisent la charge cognitive. Un nouveau contributeur sait-il d'où se synchroniser? Un exécuteur de build sait-il quel stream correspond à une nightly, un jalon ou un candidat à la version? Le propriétaire de l'intégration sait-il dans quelle direction les changements devraient circuler? Les correctifs d'urgence sont-ils traçables sans forcer du travail non lié dans le même chemin? Les artistes et les designers peuvent-ils opérer dans la même structure de projet sans comprendre chaque règle de branche?
Un client ou un régulateur peut-il voir quels changements acceptés ont atteint une version et lesquels sont restés en développement?
P4 Code Review ajoute une autre couche. Il peut transformer les listes de modifications en objets révisables et montrer les fichiers, les métadonnées, les commentaires et l'état de la revue. C'est important car la revue est là où la capacité technique devient fiabilité opérationnelle. Un fichier peut soumettre atomiquement et être néanmoins nuisible. La revue est le filtre humain et automatisé qui décide si le changement mérite l'acceptation. Le système de revue doit être suffisamment proche de l'état du dépôt pour que les réviseurs ne jugent pas un patch détaché tandis que l'état binaire réel se trouve ailleurs.
Cependant, la revue a aussi des limites. La documentation de P4 Code Review sur la limite de fichiers est un rappel inhabituellement utile que les outils ont des limites d'échelle. Un changement avec des milliers de fichiers peut ralentir ou casser une interface de revue. Un changement lourd en binaires peut nécessiter des aperçus visuels, des outils de diff spécifiques au domaine ou un réviseur capable d'ouvrir l'actif dans l'application native. Un changement de conception matérielle peut nécessiter des preuves de simulation. Un changement sensible à la sécurité peut nécessiter une visibilité restreinte.
Perforce peut fournir le changement et les hooks, mais l'équipe doit définir ce que signifie la revue pour chaque type de travail.
Le test du changement accepté devrait inclure une répétition de revue. Prenez un changement représentatif: une modification de code plus un actif binaire, une modification de niveau, un paquet de shaders, un fichier de support de carte, un calibrage logiciel automobile, ou une mise à jour de conception de semi-conducteur. Faites-le passer par le chemin prévu de stream, verrou, revue et build. Regardez ce que les réviseurs voient réellement. Regardez combien de temps ils attendent. Regardez s'ils peuvent commenter l'artefact significatif, pas seulement le fichier enveloppe. Regardez si le changement peut être rejeté proprement.
Un dépôt qui passe à l'échelle mais ne peut pas soutenir une revue significative n'est pas un système d'acceptation sûr.
L'intégration et l'automatisation sont là où Perforce gagne ou perd la confiance quotidienne
L'acceptation du dépôt ne s'arrête pas à la soumission. Le changement accepté doit être consommé par les processus de build, test, paquetage, simulation, déploiement, version ou archivage. Les témoignages de clients de Perforce pointent souvent vers cette couche intermédiaire. Warhorse Studios a décrit P4 alimentant les serveurs de build TeamCity et utilisant P4Python pour l'automatisation autour de la préparation graphique. L'histoire de Game Studio a décrit un déménagement vers Azure et l'intégration avec l'identité et l'infrastructure cloud.
ECI Telecom a souligné la traçabilité, les pistes d'audit et la gestion des espaces de travail dans un environnement de développement complexe. Ces histoires sont publiées par le fournisseur, elles ne doivent donc pas être traitées comme des benchmarks indépendants, mais elles montrent les types de tâches où Perforce est censé s'asseoir: non seulement le stockage, mais l'acceptation opérationnelle répétée.
C'est aussi là que le risque de mise en œuvre se concentre. Les systèmes de build doivent synchroniser le bon stream et la bonne révision. Les vérifications automatisées doivent s'exécuter contre la liste de modifications ou l'état soumis réel, pas une approximation proche. Les systèmes de revue doivent savoir si un changement est en attente, shelvé, promu ou validé. Les systèmes d'identité doivent mapper proprement les personnes et les comptes de service. Les autorisations doivent permettre à l'automatisation de lire ce dont elle a besoin sans transformer chaque processus de build en superutilisateur.
Les déclencheurs doivent appliquer la politique sans bloquer le serveur ou cacher les échecs derrière des scripts fragiles.
Perforce fournit des mécanismes pour cela. Sa documentation d'administration de serveur décrit des déclencheurs qui peuvent s'exécuter autour des événements de soumission, y compris les déclencheurs de pré-soumission avant le transfert des fichiers et les déclencheurs de post-validation après la commission réussie à la base de données. Elle avertit également que les commandes écrivant des données dans le dépôt à l'intérieur des scripts de déclencheur sont dangereuses, et que la récursivité et les verrous doivent être traités avec soin. Cet avertissement n'est pas une note de bas de page.
Il capture le principal risque d'automatisation: plus Perforce devient le point de contrôle d'acceptation, plus il est tentant d'accrocher chaque politique à la soumission. Une automatisation mal conçue peut transformer un système de changement accepté en une bureaucratie lente et fragile.
Une bonne automatisation est sélective. Elle vérifie les conditions qui doivent être vraies avant l'acceptation. Elle enregistre des preuves là où des preuves sont nécessaires. Elle rejette les changements tôt quand le rejet est bon marché. Elle évite de refaire un travail lourd à l'intérieur de la transaction du dépôt quand un pipeline de build séparé peut le gérer plus sûrement. Elle donne aux contributeurs des messages d'échec compréhensibles. Elle a un chemin de contournement pour les urgences, et ce contournement est lui-même auditable.
L'acheteur devrait compter le coût de maintenance de ces intégrations. P4 peut se connecter avec des outils courants et a des API, des clients et des intégrations. Mais un dépôt de qualité entreprise est rarement plug-and-play après la migration. Quelqu'un doit posséder les typemaps, les streams, les dépôts, les autorisations, les déclencheurs, les informations d'identification de build, la vérification des sauvegardes, la croissance de l'archive, la topologie proxy ou edge, la configuration des clients, la formation des utilisateurs et l'escalade du support.
Si une équipe achète Perforce pour supprimer le travail de coordination mais refuse de financer les opérations de dépôt, le travail de coordination revient sous forme de retard et de confusion.
Le meilleur argument pour Perforce n'est donc pas « nous pouvons tout automatiser ». C'est « nous pouvons expliciter les règles d'acceptation, les exécuter de manière reproductible et les maintenir dans le cadre des opérations d'ingénierie ». Cette distinction importe. L'automatisation sans propriété est une autre source d'échec.
Les équipes mondiales ont besoin de topologie et de récupération, pas seulement d'un serveur central
Perforce est souvent associé aux équipes distribuées mondialement. Le matériel produit par P4 met en avant les serveurs proxy et edge, et la documentation d'administration décrit l'architecture de commit-edge comme un modèle de serveur distribué visant à améliorer les performances et l'évolutivité pour les grandes équipes ou les équipes distribuées mondialement. C'est une capacité importante, mais c'est aussi un rappel que l'état central n'est pas physiquement simple. Une équipe mondiale a encore de la latence, des coûts de transfert, une coordination des verrous, un placement des archives et une responsabilité de sauvegarde.
La question du changement accepté devient plus complexe dans une topologie distribuée. Si un artiste à Montréal verrouille un fichier, un designer à Tokyo peut-il voir le verrou assez rapidement? Si un ingénieur soumet depuis un serveur edge, quand l'archive est-elle disponible pour le serveur de commit et les autres utilisateurs? Si une revue dépend d'une liste de modifications shelvée, a-t-elle été promue vers le serveur de commit où l'outil de revue peut la voir? Si un serveur edge a des données d'espace de travail et de travail en cours uniques, sont-elles sauvegardées séparément là où c'est nécessaire?
La documentation de Perforce aborde plusieurs de ces problèmes directement, y compris le fait que les verrous exclusifs sont globaux et peuvent nécessiter une communication avec le serveur de commit.
Cela ne sape pas le dossier de Perforce. Cela rend le dossier plus opérationnel. Les équipes avec de gros fichiers ont souvent besoin d'une infrastructure distribuée précisément parce qu'un seul point central peut être trop lent pour les contributeurs éloignés du serveur ou pour les processus de build qui déplacent du contenu lourd. Les proxys, les réplicas, les serveurs edge et le transfert d'archive en arrière-plan peuvent améliorer l'expérience utilisateur. Mais la topologie n'est pas magique.
Elle nécessite une planification de capacité, une conception réseau, des utilisateurs de service, des adresses externes, des procédures de sauvegarde et une surveillance opérationnelle.
La récupération est tout aussi centrale. La documentation de sauvegarde de Perforce distingue les fichiers versionnés des métadonnées de base de données et souligne les checkpoints, la rotation des journaux et les procédures validées. Ce n'est pas un langage générique de reprise après sinistre. Dans P4, l'état accepté vit à la fois dans les archives de fichiers et les métadonnées: utilisateurs, protections, groupes, streams, listes de modifications, fichiers ouverts, mappages de branche, labels et plus. Si les métadonnées sont perdues ou incohérentes, le dépôt peut avoir du contenu sans historique d'état accepté fiable.
Si les archives sont manquantes ou corrompues, les métadonnées seules ne suffisent pas. Un acheteur adoptant Perforce pour la traçabilité doit traiter la récupération comme une partie du produit, pas comme une réflexion après coup.
Les histoires de clients renforcent cela de différentes manières. Warhorse a décrit des checkpoints nocturnes et une sauvegarde cloud autour de son environnement P4. L'histoire publiée par le fournisseur de Tarsier a décrit la valeur de la sauvegarde et de la récupération après une corruption de données due à un problème de disque dur. L'histoire de Transurban a décrit les checkpoints et les journaux comme faisant partie du retour en arrière et de la défense contre les erreurs utilisateur. Ces récits ne sont pas une preuve indépendante que chaque déploiement Perforce est résilient.
Ils montrent que les utilisateurs sérieux de Perforce finissent souvent par discuter de sauvegarde, retour en arrière et récupération comme des avantages de premier ordre.
Pour un acheteur, le test devrait être pratique. Restaurez à partir d'une sauvegarde dans un environnement de test. Vérifiez qu'un changement accepté représentatif, y compris les fichiers binaires et les métadonnées, peut être récupéré. Testez une soumission échouée. Testez un verrou orphelin. Testez un changement de permission erroné. Testez une erreur de stream. Testez un retour en arrière d'une mauvaise liste de modifications. Un dépôt n'est pas fiable parce qu'une page de fournisseur dit qu'il passe à l'échelle. Il est fiable lorsque l'acheteur peut répéter les échecs ordinaires et récupérer sans mémoire héroïque.
L'alternative Git est réelle, donc Perforce doit gagner sur le coût total d'exploitation
Perforce ne concurrence pas une version de paille de Git. Elle concurrence un écosystème mature: GitHub, GitLab, Bitbucket, Git LFS, protection de branche, pull requests, propriétaires de code, registres d'artefacts, actifs de version, stockage cloud, gestionnaires de paquets, intégrations de moteurs de jeu et outils de gestion d'actifs tiers. Pour de nombreuses équipes, cet écosystème est moins cher, familier et plus facile à doter en personnel. Perforce doit se justifier contre cette alternative complète, et non seulement contre Git nu.
Git LFS est la comparaison la plus directe pour les gros fichiers. Le projet Git LFS décrit des fichiers pointeurs qui gardent le contenu volumineux en dehors du dépôt Git principal. La documentation de GitHub explique les limites de fichiers LFS basées sur le plan et le comportement des pointeurs. GitHub avertit également sur la santé des grands dépôts, le blocage des fichiers de 100 Mio dans les dépôts ordinaires et la taille de dépôt recommandée.
La documentation de GitLab explique que Git ne peut pas suivre les changements binaires de la même manière qu'il suit les modifications de texte et que des modifications répétées de gros fichiers augmentent la taille du dépôt; elle documente également le verrouillage de fichiers. Ces sources montrent que l'écosystème Git comprend le problème des gros fichiers.
Perforce gagne lorsque le coût de l'acheteur n'est pas simplement « gros fichiers » mais « changements d'actifs multi-rôles acceptés ». Si le code est dans Git, l'art dans LFS, la revue dans des pull requests, le verrouillage binaire optionnel, les artefacts de build ailleurs, et que les producteurs suivent l'approbation dans un autre système, le processus total peut devenir difficile à raisonner. Perforce peut simplifier le modèle opérationnel en mettant le code source, l'état binaire, les verrous, les listes de modifications, les streams, les autorisations et les outils de revue adjacents sous un seul plan de contrôle de dépôt.
C'est précieux lorsque le coût de l'incohérence est élevé.
Perforce perd lorsque l'acheteur n'a pas besoin de ce plan de contrôle ou ne peut pas le maintenir. Une petite équipe logicielle avec principalement du code texte peut en tirer peu d'avantages. Une entreprise cloud-native dont les sorties de build sont reproductibles et dont les gros actifs sont mieux gérés dans le stockage d'objets peut ne pas avoir besoin de P4. Un studio qui manque de discipline d'administration de dépôt peut connaître de la contention de verrous, de la confusion de streams et une dépendance coûteuse au support.
Une équipe qui a déjà une configuration Git LFS et de revue d'actifs réussie peut trouver le risque de migration supérieur aux économies de coordination.
Le test commercial devrait inclure le coût de licence, l'effectif d'administration, la formation, la migration, l'intégration, l'infrastructure de sauvegarde, la croissance du stockage, l'outillage de revue, l'accès des sous-traitants, le support, les options d'hébergement cloud et le coût de sortie. Le coût de sortie mérite une attention particulière. Perforce peut devenir un dépôt profond de code, d'art, d'historique, d'autorisations, de listes de modifications, de labels, de streams et d'hypothèses de processus. Cette profondeur est utile tant que le système fonctionne. C'est aussi un enfermement propriétaire.
Un acheteur devrait comprendre ce qu'il faudrait pour exporter l'historique, déplacer les binaires, préserver la traçabilité et reformer les utilisateurs si la relation commerciale ou la stratégie d'outil change.
La conclusion équitable n'est pas que Perforce est cher ou bon marché dans l'abstrait. C'est que Perforce n'est économique que lorsque le coût de changement accepté qu'il supprime est plus grand que le coût de plateforme qu'il ajoute. Pour les grandes organisations d'actifs binaires, cela peut être vrai. Pour les dépôts de code ordinaires, ce n'est souvent pas le cas.
Les preuves clients soutiennent des modèles, pas des affirmations de performance universelles
Les preuves clients publiques de Perforce sont utiles lorsqu'elles sont lues attentivement. Warhorse Studios a rapporté être passé de Subversion et Mercurial, en consolidant les actifs numériques, en utilisant un verrouillage strict des fichiers et en alimentant des builds automatisés. Game Studio a décrit l'exécution de Helix Core sur Azure après des problèmes liés à l'utilisation simultanée de Subversion et Git, y compris des échecs de fusion et des incohérences de données. L'étude de cas de NVIDIA place P4 dans un contexte de contrôle des modifications de conception de puce et de documents d'entreprise.
ECI Telecom décrit un environnement de développement international complexe et souligne les pistes d'audit, la gestion des espaces de travail et le support. Amdocs discute de la migration depuis ClearCase tout en préservant l'historique et en gérant la transition équipe par équipe. Halon et Tarsier fournissent des exemples de jeux et de développement multimédia autour des limitations de Git ou SVN, des actifs et de la visibilité. Transurban met l'accent sur les déploiements plus importants, le retour en arrière et la valeur des journaux/checkpoints.
Ces histoires sont alignées avec la thèse du changement accepté. Ce ne sont pas des endorsements aléatoires. Elles se regroupent autour de tâches de production répétées: gérer de gros fichiers binaires, maintenir une source unique de vérité, intégrer avec des systèmes de build, soutenir des équipes distribuées, préserver l'auditabilité, migrer depuis des systèmes de contrôle de version plus anciens et récupérer des erreurs. Ce sont les tâches que Perforce est censé faire.
Elles ont aussi des limites. La plupart sont publiées par le fournisseur. Certaines sont suffisamment anciennes pour que les détails ne représentent pas l'infrastructure, les noms de produits, la tarification ou les limites de support actuelles. Certaines décrivent des environnements clients spécifiques qui ne peuvent pas être généralisés. Un studio avec 75 utilisateurs et 3 To de fichiers n'est pas la même chose qu'une entreprise de semi-conducteurs, un fournisseur automobile ou une petite équipe de jeu indépendante.
Un déploiement cloud sur Azure n'est pas une preuve que chaque déploiement P4 Cloud ou auto-hébergé atteindra la même cible de performance. Une amélioration rapportée par rapport à SVN ou Mercurial n'est pas une preuve d'amélioration par rapport à une pile Git LFS et de gestion d'actifs bien conçue.
Cette distinction importe car les acheteurs abusent souvent des études de cas. Ils cherchent un logo ou une métrique dramatique et la traitent comme une promesse. Le meilleur usage est la reconnaissance de motifs. Les preuves publiques montrent-elles Perforce utilisé pour le type de problème de changement accepté que l'acheteur a? Si oui, le produit est plausible. Les preuves prouvent-elles la latence, la contention de verrous, le coût de stockage, l'adoption par les utilisateurs, le modèle de branche ou le résultat du support de l'acheteur? Non. Cela nécessite toujours un test mené par l'acheteur.
Il en va de même des affirmations d'échelle de Perforce, y compris la confiance parmi les meilleures entreprises de jeux et de semi-conducteurs et les déclarations d'enquête sur le retour sur investissement. Elles indiquent la position sur le marché et la perception des clients. Elles ne remplacent pas la diligence. Un acheteur devrait demander des références actuelles dans son propre domaine, mener un projet pilote représentatif et mesurer le coût de déplacement d'un changement réel à travers le système. L'adoption par le marché réduit le risque d'adoption, mais elle ne supprime pas le risque de mise en œuvre.
Le jugement de l'article est donc modéré plutôt que promotionnel. Les preuves publiques soutiennent Perforce comme un plan de contrôle sérieux pour les changements de code source et d'actifs acceptés dans les grands environnements binaires et réglementés. Elles ne prouvent pas que Perforce battra les alternatives pour chaque équipe, chaque dépôt ou chaque modèle de coût.
Les principaux modes d'échec ne sont pas exotiques
Les modes d'échec connus de Perforce sont assez ordinaires pour être dangereux: contention de verrous, retard de réplication, erreurs de permission, fusions échouées, corruption d'actifs binaires, ruptures d'intégration de build, confusion de branche, lacunes d'audit, dépassements de coût de stockage et impasses de migration. Aucun de ceux-ci ne nécessite une défaillance dramatique du produit. Ils peuvent émerger d'une croissance normale.
La contention de verrous peut commencer comme un problème résolu et devenir un problème de planification. Si des fichiers clés sont verrouillés pendant de longues périodes, d'autres contributeurs attendent ou créent des solutions de contournement. Si des gens oublient des verrous, les administrateurs interviennent. Si les verrous sont trop larges, la productivité chute. S'ils sont trop étroits, des conflits non fusionnables reviennent. Le processus de changement accepté devrait définir les attentes de durée de verrouillage, la visibilité de la propriété, l'escalade et le nettoyage.
La réplication et la topologie edge peuvent améliorer les performances mondiales mais ajoutent des détails de coordination. Si une soumission, un shelve ou une revue dépend d'un serveur edge, d'un serveur de commit et d'un outil de revue voyant le même état, les retards et les règles de promotion comptent. Si un verrou global nécessite une communication avec le serveur de commit, la latence compte. Si un serveur edge stocke des données uniques d'espace de travail et de travail en cours, les choix de sauvegarde comptent. Ce sont des problèmes gérables, mais seulement s'ils sont traités comme faisant partie du modèle opérationnel.
Les permissions peuvent échouer dans les deux sens. Trop peu d'accès bloque le travail, casse les builds et pousse les utilisateurs vers des systèmes de l'ombre. Trop d'accès expose des IP confidentielles ou permet des modifications accidentelles dans des zones sensibles. Les protections P4 peuvent contrôler les commandes par utilisateur, hôte et emplacement de dépôt, mais les règles nécessitent conception, revue et test. Une erreur de permission dans un dépôt qui contient du code, de l'art, des données de conception et des artefacts de version peut avoir un impact plus large qu'une erreur dans un dépôt de code étroit.
La confusion de branche et de stream est un autre risque courant. Les Perforce Streams peuvent structurer le travail, mais seulement si le modèle de stream reflète la manière dont l'organisation publie réellement. Si le modèle est trop rigide, les équipes le contournent. S'il est trop lâche, l'intégration devient floue. Si les branches de version, de contenu et de plateforme ne sont pas nommées et gouvernées correctement, l'état accepté devient local plutôt que partagé.
Le risque de migration est souvent sous-estimé. Passer de Git, SVN, ClearCase, de partages de fichiers ou de systèmes mixtes à Perforce n'est pas seulement un transfert de données. C'est un changement d'habitudes. Les artistes peuvent avoir besoin de comprendre l'extraction et les verrous. Les développeurs peuvent devoir s'adapter des habitudes de commit local à la discipline de soumission centrale. Les systèmes de build ont besoin d'une nouvelle logique de synchronisation. L'historique peut être incomplet ou trop coûteux à préserver en totalité.
Les liens existants entre les tickets, les artefacts, les pull requests et les artefacts peuvent se rompre. L'état cible peut être meilleur, mais la transition elle-même a un coût.
La leçon est que les échecs de Perforce sont généralement socio-techniques. Le produit donne des contrôles puissants. Une mauvaise gouvernance transforme ces contrôles en retard. Une bonne gouvernance les transforme en fiabilité de l'état accepté.
Un acheteur devrait mener une répétition de changement accepté avant de croire l'histoire
L'évaluation la plus utile de Perforce n'est pas une preuve de concept générique. C'est une répétition de changement accepté. L'acheteur devrait choisir un changement représentatif de son travail réel: un grand actif Unreal ou Unity plus du code associé, une mise à jour de scène VFX, un ensemble de fichiers de conception matérielle, un calibrage logiciel automobile, un changement de système de build avec des artefacts générés, ou un correctif réglementé nécessitant de la traçabilité. Le but est de mesurer le chemin du travail proposé à l'état accepté de confiance.
La répétition devrait commencer avant que le fichier ne soit ajouté. La typemap est-elle correcte? Le fichier est-il verrouillable s'il devrait l'être? La vue de l'espace de travail inclut-elle seulement ce dont le contributeur a besoin? Le contributeur comprend-il comment extraire, éditer, verrouiller, shelver, réviser, soumettre et annuler? Un non-développeur peut-il utiliser le bon outil, que ce soit P4V, P4 DAM, un plugin ou un autre client, sans dépendre d'un spécialiste du dépôt pour chaque étape?
Vient ensuite la revue. La liste de modifications a-t-elle la bonne portée? Les réviseurs peuvent-ils voir les modifications de texte, les changements d'image, les métadonnées et les aperçus d'actifs là où c'est nécessaire? Le système de revue gère-t-il le nombre et la taille des fichiers? La revue est-elle connectée au problème, à la tâche, au build ou à la preuve d'approbation qui compte? Si le changement est mauvais, le réviseur peut-il le rejeter sans laisser de verrous orphelins, d'étagères périmées ou d'étapes suivantes peu claires?
Puis vient l'intégration. Le processus de build ou de validation s'exécute-t-il sur le changement exact ou la révision acceptée? Se synchronise-t-il efficacement? Gère-t-il le coût de transfert binaire? Rapporte-t-il l'échec clairement? Les informations d'identification de service sont-elles limitées mais suffisantes? Si un déclencheur de soumission est utilisé, rejette-t-il les mauvaises entrées tôt sans faire de travail lourd dans le chemin de soumission? Si le build passe après la soumission plutôt qu'avant, y a-t-il une politique claire de retour en arrière ou de correctif en avant?
Vient enfin la récupération. Annulez un changement en attente. Défaites ou annulez un changement accepté dans un environnement de test. Restaurez à partir d'une sauvegarde. Effacez un verrou abandonné. Réparez une erreur de permission. Déplacez un changement à travers les streams. Demandez si l'équipe peut expliquer ce qui s'est passé sans se fier à la mémoire d'une seule personne. Si la réponse est oui, Perforce fait plus que stocker des fichiers. Il rend l'état accepté opérationnel.
La répétition devrait également tester les alternatives. Exécutez le même changement à travers le processus actuel Git LFS, stockage cloud ou gestion d'actifs. Incluez le temps que les gens passent à attendre, chercher, demander la permission, résoudre les conflits, confirmer l'état du build et documenter les preuves. De nombreuses décisions d'outils semblent différentes lorsque le coût de coordination est compté. Une licence moins chère peut cacher un travail humain coûteux. Une plateforme plus chère peut être économique si elle supprime la confusion répétée.
Perforce ne devrait gagner que s'il gagne cette répétition sous des contraintes réalistes. Un petit dépôt de démonstration prouve peu. Une répétition de changement accepté soigneusement choisie dit à l'acheteur si Perforce réduit le travail qui compte vraiment.
Le verdict: fort là où les changements d'actifs acceptés sont coûteux, conditionnel partout ailleurs
Perforce Software, Inc. a une position crédible et encore importante dans le contrôle de version parce que certaines équipes n'ont pas seulement besoin d'hébergement de code. Elles ont besoin d'un état de dépôt accepté pour le code, les actifs binaires, les données de conception, la revue, les autorisations, l'intégration de build et la récupération. P4, P4V, P4 Code Review, P4 DAM, les streams, les verrous, les listes de modifications, les déclencheurs, les proxys, l'architecture edge et les pratiques de récupération forment une réponse cohérente à ce problème lorsqu'ils sont bien mis en œuvre.
L'adéquation la plus forte est une équipe où de grands changements de conception binaires ou structurés sont fréquents, les échecs de fusion sont coûteux, l'auditabilité importe, de multiples rôles partagent l'état du projet et la chaîne d'outils actuelle passe déjà trop de temps humain en coordination. Les studios de jeux, les équipes de production virtuelle, les groupes de semi-conducteurs, les organisations logicielles automobiles et d'autres grands groupes d'ingénierie lourds en actifs correspondent plus souvent à ce profil que les équipes logicielles ordinaires.
Pour eux, le changement d'actif accepté est un problème opérationnel sérieux, pas une préférence de dépôt.
L'adéquation la plus faible est une équipe qui écrit principalement du code texte, a des builds reproductibles, utilise efficacement la revue native de Git, stocke les artefacts dans les bons systèmes externes et ne souffre pas beaucoup de la coordination binaire. Pour cet acheteur, Perforce peut être un système puissant résolvant le mauvais problème. Il peut introduire de l'administration, des coûts et de l'enfermement sans gain compensatoire suffisant.
La question commerciale de Perforce n'est donc pas « Est-ce meilleur que Git? » C'est « Rend-il les changements acceptés moins chers et plus sûrs que l'alternative complète de l'acheteur? » Cette alternative peut inclure Git, LFS, des magasins d'artefacts, du stockage cloud, le suivi des problèmes, la protection de branche, les revues, les pipelines de build et les outils d'actifs. Perforce doit battre le processus combiné, pas une caricature simplifiée.
Un acheteur discipliné devrait juger Perforce par un changement réel, pas par des affirmations d'échelle de dépôt. Le changement devrait inclure les parties inconfortables: fichiers binaires, verrous, revue, intégration de build, autorisations, retour en arrière et récupération. Si Perforce rend ce changement plus clair, plus rapide, plus sûr et plus auditable, sa valeur est concrète. S'il stocke simplement les fichiers pendant que l'organisation continue de se disputer sur la propriété, les règles de branche et les critères d'acceptation, la plateforme n'a pas résolu le problème.
C'est le dossier étroit mais durable pour Perforce. Sa valeur n'est pas qu'il peut contenir un vaste dépôt. Sa valeur est que, dans le bon environnement, il peut faire accepter un changement difficile avec moins d'ambiguïté et moins de gaspillage. La responsabilité de l'acheteur est de prouver que cela est vrai pour son propre travail avant que le dépôt ne devienne trop important pour être quitté.