Perforce pour les utilisateurs de Git?

Question

Il existe une grande quantité de documentation sur les utilisateurs de Git for Perforce, mais il semble que l’inverse soit très peu apparent.

Je n'utilisais que Git auparavant et j'ai récemment commencé un travail où je dois beaucoup utiliser Perforce, et je me trouve très confus beaucoup de temps. Les concepts de Git auxquels je suis habitué ne semblent pas du tout mapper à Perforce.

Quelqu'un est-il intéressé par quelques conseils d'utilisation de Perforce pour quelqu'un qui est habitué à Git?

Answer 1

C'est quelque chose sur lequel j'ai travaillé de façon intermittente au cours des deux dernières semaines. Cela continue d'évoluer, mais cela peut être utile. Veuillez noter que je suis un employé de Perforce.

Une introduction à Perforce pour les utilisateurs de Git

Dire que passer de Git à Perforce ou de Perforce à Git n’est pas anodin est un grand euphémisme. Pour être deux outils qui font apparemment la même chose, leur approche ne pourrait pas être plus différente. Cette brève description tentera d’aider les nouveaux utilisateurs de Perforce venant de Git à comprendre le nouveau monde dans lequel ils se trouvent.

Un bref détour avant de plonger; si vous préférez Git, vous pouvez très bien utiliser Git avec Perforce. Nous fournissons un outil appelé Git Fusion qui génère des référentiels Git synchronisés avec le serveur Perforce. Les personnes de Git et de Perforce peuvent vivre en harmonie en travaillant sur le même code, en général indifférentes au choix de contrôle de version de leurs collègues. Git Fusions 13.3 est disponible sur le site site Web Perforce . Il doit être installé par l'administrateur Perforce, mais si vous l'installez, vous constaterez que la fonction de découpage en tranches du référentiel peut s'avérer très pratique pour un utilisateur Git.

Si vous ne pouvez pas convaincre votre administrateur d'installer Git Fusion, Git est livré avec une liaison Perforce appelée Git-P4 qui vous permet d'utiliser Git pour modifier et soumettre des fichiers dans un espace de travail Perforce. Plus d'informations à ce sujet peuvent être trouvées sur: https://git.wiki.kernel.org/index.php/GitP4

Toujours là? Bien, regardons Perforce.

Quelques différences terminologiques à trier

Avant d'entrer dans les détails, nous devons couvrir brièvement quelques différences de terminologie entre Git et Perforce.

Le premier est la caisse . Dans Git, vous obtenez une copie du code d’une branche donnée dans votre zone de travail. Dans Perforce, nous appelons cela une synchronisation à partir de la ligne de commande ou de notre interface graphique P4V "Obtenir la dernière révision". Perforce utilise le contrôle de mot de P4V ou p4 edit sur la ligne de commande pour indiquer que vous envisagez de modifier un fichier à partir du système de contrôle de version. Dans la suite de ce document, j'utiliserai le paiement au sens strict du terme.

Le second est Git commit contre Perforce submit . Où vous vous engageriez dans Git, vous le soumettriez dans Perforce. Étant donné que toutes les opérations ont lieu contre le service de gestion de version Perforce partagé, Perforce n’a pas d’équivalent pour git Push. De même, nous n'avons pas de pull; la commande de synchronisation ci-dessus s'occupe de récupérer les fichiers pour nous. Il n'y a pas de concept de soumission locale pure dans Perforce, sauf si vous choisissez d'utiliser notre outil P4Sandbox décrit brièvement ci-dessous.

Concepts clés en vigueur

Si je devais simplifier Perforce en deux concepts clés, je me concentrerais sur le dépôt et l'espace de travail. Un dépôt Perforce est un référentiel de fichiers hébergés sur un serveur Perforce. Un serveur Perforce peut avoir un nombre quelconque de dépôts et chaque dépôt peut contenir un nombre quelconque de fichiers. Vous entendrez souvent les utilisateurs de Perforce utiliser le dépôt et le serveur de manière interchangeable, mais ils sont différents. Un site Perforce peut choisir de disposer de plusieurs serveurs, mais le plus souvent, tous les fichiers se trouvent sur un seul serveur.

Un espace de travail ou un client Perforce est un objet du système qui mappe un ensemble de fichiers du serveur Perforce sur un emplacement du système de fichiers d'un utilisateur. Chaque utilisateur dispose d'un espace de travail pour chaque machine qu'il utilise et les utilisateurs disposent souvent de plusieurs espaces de travail pour la même machine. La partie la plus importante d'un espace de travail est le mappage ou la vue d'espace de travail.

La vue de l'espace de travail spécifie l'ensemble des fichiers du dépôt qui doivent être mappés sur la machine locale. Ceci est important car il y a de fortes chances que vous ne souhaitiez pas tous les fichiers disponibles sur le serveur. Une vue de l’espace de travail vous permet de sélectionner uniquement l’ensemble qui vous tient à cœur. Il est important de noter qu'un espace de travail peut mapper le contenu de plusieurs dépôts, mais ne peut mapper que le contenu d'un serveur.

Pour comparer Perforce à Git à cet égard, avec Git, vous choisissez l’ensemble de repos Git qui vous intéresse. Chaque référentiel est généralement conçu pour ne contenir que des fichiers liés. L'avantage de ceci est qu'il n'y a pas de configuration à faire de votre part; vous faites un clone des choses qui vous tiennent à cœur et vous avez terminé. Ceci est particulièrement utile si vous ne travaillez qu'avec un ou deux référentiels. Avec Perforce, vous devez passer un peu de temps à choisir les bits de code que vous souhaitez.

De nombreux magasins Perforce utilisent des flux pouvant générer automatiquement une vue d'espace de travail ou à l'aide de scripts ou d'espaces de travail de modèles. De même, beaucoup quittent leurs utilisateurs pour créer leurs espaces de travail eux-mêmes. L'un des avantages de pouvoir mapper un certain nombre de modules dans un espace de travail est que vous pouvez facilement modifier plusieurs modules de code en un seul enregistrement. vous pouvez être assuré que toute personne avec une vue client similaire qui se synchronise avec votre enregistrement aura tout le code dans le bon état. Cela peut aussi conduire à un code trop dépendant; la séparation forcée de Git peut conduire à une meilleure modularité. Heureusement, Perforce peut également prendre en charge une modularité stricte. Tout dépend de la manière dont vous choisissez d'utiliser l'outil.

Pourquoi des espaces de travail?

Je pense qu'en venant de Git, il est facile de se sentir comme si tout le concept d'espace de travail posait bien plus de problèmes qu'il n'en valait la peine. Comparé au clonage de quelques dépôts Git, cela est sans aucun doute vrai. Là où les espaces de travail brillent et pourquoi Perforce est toujours en activité après toutes ces années, c’est un excellent moyen de réduire les projets de plusieurs millions de fichiers destinés aux développeurs, tout en facilitant la compilation et la publication de toutes les sources. une source faisant autorité. Les espaces de travail sont l’une des principales raisons pour lesquelles Perforce peut évoluer aussi bien qu’il le fait.

Les espaces de travail sont également intéressants dans la mesure où la disposition des fichiers dans le dépôt et la disposition sur la machine de l'utilisateur peuvent varier le cas échéant. De nombreuses entreprises organisent leur dépôt de manière à refléter l'organisation de leur entreprise de sorte qu'il soit facile pour les personnes de trouver du contenu par division ou par projet. Cependant, leur système de construction se fichait totalement de cette hiérarchie; l'espace de travail leur permet de remapper la hiérarchie de leurs dépôts de la manière qui leur convient le mieux. J'ai également vu cela utiliser par des entreprises qui utilisent des systèmes de compilation extrêmement inflexibles qui nécessitent que le code soit dans des configurations très spécifiques qui déroutent les humains. Les espaces de travail permettent à ces sociétés d’avoir une hiérarchie de sources qui permet une navigation humaine, tandis que leurs outils de génération obtiennent la structure dont ils ont besoin.

Les espaces de travail dans Perforce ne sont pas seulement utilisés pour mapper l'ensemble des fichiers avec lesquels un utilisateur souhaite travailler, mais ils sont également utilisés par le serveur pour suivre exactement les révisions de chaque fichier que l'utilisateur a synchronisé. Cela permet au système d'envoyer le jeu de fichiers correct à l'utilisateur lors de la synchronisation sans avoir à analyser les fichiers pour voir quels fichiers doivent être mis à jour. Avec de grandes quantités de données, cela peut représenter un gain de performances considérable. Ceci est également très populaire dans les industries soumises à des règles d'audit très strictes; Les administrateurs Perforce peuvent facilement suivre et consigner les développeurs qui ont synchronisé quels fichiers.

Pour plus d'informations sur la pleine puissance des espaces de travail Perforce, consultez la section Configuration de P4 .

Paiement explicite contre paiement implicite

L'un des plus grands défis pour les utilisateurs passant de Git à Perforce est le concept de paiement explicite. Si vous êtes habitué au flux de travaux Git/SVN/CVS consistant à modifier les fichiers, puis à demander au système de contrôle de version de rechercher ce que vous avez fait, la transition peut s'avérer extrêmement pénible.

La bonne nouvelle est que si vous le souhaitez, vous pouvez utiliser un flux de travail de style Git dans Perforce. Dans Perforce, vous pouvez définir l'option "allwrite" sur votre espace de travail. Cela indiquera à Perforce que tous les fichiers doivent être écrits sur le disque avec le bit en écriture défini. Vous pouvez ensuite modifier n’importe quel fichier sans le dire explicitement à Perforce. Pour que Perforce réconcilie les modifications que vous avez apportées, vous pouvez exécuter "statut p4". Il ouvrira des fichiers pour ajouter, éditer et supprimer selon les besoins. Lorsque vous travaillez de cette façon, vous voudrez utiliser "p4 update" au lieu de "p4 sync" pour obtenir les nouvelles révisions du serveur; "p4 update" vérifie les modifications avant la synchronisation, de sorte que vos modifications locales ne seront pas annulées si vous n'avez pas encore exécuté "p4 status".

Pourquoi la commande explicite?

Une question que je reçois fréquemment est "pourquoi voudriez-vous jamais utiliser le paiement explicite?" À première vue, cela peut sembler être une décision de conception folle, mais le paiement explicite présente de puissants avantages.

L’utilisation de la vérification explicite est notamment motivée par le fait qu’elle supprime la nécessité d’analyser les fichiers pour rechercher les modifications de contenu. Tandis qu'avec des projets plus petits, calculer les hachages de chaque fichier pour trouver les différences est assez économique, beaucoup de nos utilisateurs ont des millions de fichiers dans un espace de travail et/ou des fichiers de 100 mégaoctets, voire plus. Le calcul de tous les hachages dans ces cas prend énormément de temps. L'extraction explicite permet à Perforce de savoir exactement avec quels fichiers il doit travailler. Ce comportement est l'une des raisons pour lesquelles Perforce est si populaire dans les industries de gros fichiers comme les industries du jeu, du cinéma et du matériel.

Un autre avantage est que le paiement explicite fournit une forme de communication asynchrone qui permet aux développeurs de savoir en général sur quoi leurs homologues travaillent, ou au moins où. Il peut vous faire savoir que vous souhaitez peut-être éviter de travailler dans une zone donnée afin d'éviter un conflit inutile ou vous alerter du fait qu'un nouveau développeur de l'équipe a erré dans du code dont il n'a peut-être pas besoin. être éditer. D'après mon expérience personnelle, j'ai tendance à travailler soit avec Git, soit avec Perforce avec allwrite sur des projets pour lesquels je suis l'unique contributeur ou un contributeur occasionnel, et une commande explicite lorsque je travaille en étroite collaboration avec une équipe. Heureusement, le choix vous appartient.

Le paiement explicite joue également à merveille avec le concept Perforce de listes de modifications en attente. Les listes de modifications en attente sont des compartiments dans lesquels vous pouvez placer vos fichiers ouverts pour organiser votre travail. Dans Git, vous utiliseriez potentiellement différentes branches en tant que compartiments pour organiser le travail. Les branches sont excellentes, mais il est parfois agréable de pouvoir organiser votre travail en plusieurs modifications nommées avant de les soumettre au serveur. Avec le modèle Perforce de mappage potentiel de plusieurs branches ou de plusieurs projets dans un seul espace de travail, les listes de modifications en attente facilitent l'organisation de modifications distinctes.

Si vous utilisez un IDE pour le développement tel que Visual Studio ou Eclipse, je vous recommande fortement d'installer un plugin Perforce pour votre IDE. La plupart des IDE extrairont automatiquement les fichiers lorsque vous commencez à les éditer, ce qui vous évite de faire la caisse vous-même.

Perforce Replacements For Git Caractéristiques

• git stash ==> p4 shelve
• branchement local git ==> Perforcez les étagères ou les branches de tâches
• git blame ==> p4 annotate ou Perforce Timelapse View à partir de l'interface graphique

Travailler déconnecté

Il existe deux options pour travailler déconnecté du service de contrôle de version Perforce (c'est notre terme de fantaisie pour le serveur Perforce).

1) Utilisez P4Sandbox pour obtenir une gestion complète des versions locales et des branches

2) Modifiez les fichiers à votre guise et utilisez "Statut p4" pour indiquer à Perforce ce que vous avez fait.

Avec les deux options ci-dessus, vous pouvez choisir d'utiliser le paramètre "allwrite" dans votre espace de travail afin de ne pas avoir à déverrouiller les fichiers. Lorsque vous travaillez dans ce mode, vous voudrez utiliser la commande "p4 update" pour synchroniser les nouveaux fichiers au lieu de "p4 sync". "Mise à jour p4" vérifiera les modifications apportées aux fichiers avant leur synchronisation.

Perforce Quickstart

Tous les exemples suivants seront via la ligne de commande.

1) Configurez votre connexion à Perforce

export P4USER=matt
export P4CLIENT=demo-workspace
export P4PORT=perforce:1666

Vous pouvez coller ces paramètres dans votre fichier de configuration Shell, utilisez p4 set pour les enregistrer sous Windows et OS X, ou utilisez un fichier de configuration Perforce.

1) Créer un espace de travail

p4 workspace

# set your root to where your files should live:
Root: /Users/matt/work

# in the resulting editor change your view to map the depot files you care about
//depot/main/... //demo-workspace/main/...
//depot/dev/...  //demo-workspace/dev/...

2) Obtenir les fichiers du serveur

cd /Users/matt/work
p4 sync

3) Extraire le fichier sur lequel vous voulez travailler et le modifier

p4 edit main/foo; 
echo cake >> main/foo

4) Soumettez-le au serveur

p4 submit -d "A trivial edit"

5) Run p4 help simple pour voir les commandes de base dont vous aurez besoin pour travailler avec Perforce.

Answer 2

La plus grande différence entre git et p4, qu'aucune des réponses existantes n’adresse, c’est qu’ils utilisent différentes unités d’abstraction.

• Dans git, l'abstraction est le correctif (aka diff, aka changeset). Un commit in git est essentiellement le résultat de l'exécution de diff entre l'état précédent et actuel des fichiers en cours de validation.
• Forcément, l'abstraction est le fichier . Un commit en p4 est le contenu complet des fichiers dans le commit à ce moment-là. Cette liste est organisée dans une liste de modifications, mais les révisions elles-mêmes sont stockées par fichier et la liste de modifications rassemble simplement différentes révisions des fichiers.

Tout le reste découle de cette différence. Il est facile de créer des branches et de les fusionner dans git car, du point de vue de l'abstraction de git, chaque fichier peut être entièrement reconstruit en appliquant un ensemble de correctifs dans l'ordre. Par conséquent, pour fusionner deux branches, il vous suffit d'appliquer tous les correctifs de la branche source. qui ne sont pas présents dans la branche cible de la branche cible dans le bon ordre (en supposant qu'aucun correctif ne se chevauche sur les deux branches).

Les branches sont forcément différentes. Une opération de branche va forcément copier les fichiers d'un sous-dossier à un autre, puis marquer le lien entre les fichiers et les métadonnées sur le serveur. Pour fusionner un fichier d'une branche à une autre (integration en termes impératifs), il faudra forcément examiner le contenu complet du fichier à l'adresse la 'tête' de sur la branche source et le contenu complet du fichier situé en tête de la branche cible et, si nécessaire, fusionnés à l'aide d'un ancêtre commun. Il est incapable d'appliquer les correctifs un à un comme git can, ce qui signifie que les fusions manuelles se produisent plus souvent (et ont tendance à être plus douloureuses).

Answer 3

Il n'y a probablement pas beaucoup de documentation de ce type car Perforce est un système de contrôle de révision assez traditionnel (plus proche de CVS, Subversion, etc.) et est généralement considéré comme moins complexe que les systèmes de contrôle de révision distribués modernes.

Essayer de mapper des commandes de l'une à l'autre n'est pas la bonne approche; Les concepts des systèmes de contrôle de révision centralisés et distribués ne sont pas les mêmes. Au lieu de cela, je vais décrire un flux de travail typique dans Perforce:

1. Courir p4 edit sur chaque fichier à modifier. Vous devez dire à Perforce quels fichiers vous éditez. Si vous ajoutez de nouveaux fichiers, utilisez p4 add. Si vous supprimez des fichiers, utilisez p4 delete.
2. Faites vos changements de code.
3. Courir p4 change pour créer un changeset. Vous pouvez ici créer une description de votre modification et éventuellement ajouter ou supprimer des fichiers de votre ensemble de modifications. Tu peux courir p4 change CHANGE_NUMBER pour modifier la description ultérieurement si nécessaire.
4. Vous pouvez apporter des modifications supplémentaires au code si vous en avez besoin. Si vous devez ajouter/modifier/supprimer d’autres fichiers, vous pouvez utiliser p4 {add,edit,delete} -c CHANGE_NUMBER FILE.
5. Courir p4 sync pour extraire les dernières modifications du serveur.
6. Courir p4 resolve pour résoudre les conflits liés à la synchronisation.
7. Lorsque vous êtes prêt à soumettre votre modification, exécutez p4 submit -c CHANGE_NUMBER.

Vous pouvez utiliser p4 revert pour revenir aux modifications apportées aux fichiers.

Notez que vous pouvez travailler sur plusieurs ensembles de modifications simultanément, à condition qu'aucun de leurs fichiers ne se chevauche. (Un fichier de votre client Perforce ne peut être ouvert que dans un ensemble de modifications à la fois.) Cela peut parfois être pratique si vous devez effectuer de petites modifications indépendantes.

Si vous avez besoin de modifier des fichiers déjà ouverts dans un autre groupe de modifications, vous pouvez créer un client Perforce distinct ou stocker votre groupe de modifications existant pour plus tard via p4 shelve. (Contrairement à git stash, shelving ne rétablit pas les fichiers de votre arborescence locale, vous devez donc les restaurer séparément.)