Il y a beaucoup de documentation "Git pour les utilisateurs Perforce", mais apparemment très peu du contraire.

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

Quelqu'un est-il intéressé à rassembler quelques astuces pour utiliser Perforce pour quelqu'un qui est habitué à Git?

C'est quelque chose sur lequel j'ai travaillé au cours des deux dernières semaines. Cela évolue encore, 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 trivial est un grand euphémisme. Pour être deux outils qui font apparemment la même chose, leur approche ne pourrait ê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 qui sont synchronisés avec le serveur Perforce. Les utilisateurs de Git et Perforce peuvent vivre en harmonie en travaillant sur le même code, la plupart du temps sans être affectés par le choix de contrôle de version de leurs collègues. Git Fusions 13.3 est disponible sur le site Web de Perforce . Il doit être installé par l'administrateur Perforce, mais si vous l'installez, vous constaterez que sa fonction de découpage du référentiel peut être très pratique en tant qu'utilisateur Git.

Si vous ne pouvez pas convaincre votre administrateur d'installer Git Fusion, Git lui-même 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 sur: https://git.wiki.kernel.org/index.php/GitP4

Toujours là? Bon, regardons Perforce.

Quelques différences de terminologie à trier

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

Le premier est le paiement . Dans Git, c'est ainsi que vous obtenez une copie du code d'une branche donnée dans votre zone de travail. Dans Perforce, nous appelons cela une synchronisation depuis la ligne de commande ou depuis notre interface graphique P4V "Get Latest Revision". Perforce utilise le mot extraction de P4V ou p4 editde la ligne de commande pour signifier que vous prévoyez de modifier un fichier à partir du système de contrôle de version. Dans le reste de ce document, j'utiliserai checkout dans le sens Perforce du mot.

Le second est Git commit contre Perforce submit . Où vous vous engagez dans Git, vous le soumettez dans Perforce. Étant donné que toutes les opérations se déroulent sur le service de gestion de versions Perforce partagé, Perforce n'a pas d'équivalent pour git push. De même, nous n'avons pas de pull; la commande sync 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 de Perforce

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 qui réside dans un serveur Perforce. Un serveur Perforce peut avoir n'importe quel nombre de dépôts et chaque dépôt peut contenir n'importe quel nombre 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 d'avoir 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 à 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 auront souvent plus d'un espace de travail pour la même machine. La partie la plus importante d'un espace de travail est le mappage ou la vue de l'espace de travail.

La vue de l'espace de travail spécifie l'ensemble de fichiers dans le 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 vouliez 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 intéresse. 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 dépôts Git qui vous intéresse. Chaque dépôt est généralement étroitement limité pour contenir uniquement les fichiers associés. L'avantage de ceci est qu'il n'y a aucune configuration à faire de votre part; vous faites un clone git des choses qui vous intéressent et vous avez terminé. C'est particulièrement intéressant 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 ateliers Perforce utilisent des flux qui peuvent générer automatiquement une vue d'espace de travail, ou ils génèrent la vue à l'aide de scripts ou d'espaces de travail modèles. De même, beaucoup quittent leurs utilisateurs pour générer eux-mêmes leurs espaces de travail. L'un des avantages de pouvoir mapper un certain nombre de modules dans un même espace de travail est que vous pouvez facilement modifier plusieurs modules de code en un seul enregistrement; vous pouvez être assuré que toute personne ayant une vue client similaire qui se synchronise avec votre enregistrement aura tout le code dans le bon état. Cela peut également 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 les espaces de travail?

Je pense qu'en venant de Git, il est facile de penser que tout le concept d'espace de travail pose bien plus de problèmes qu'il n'en vaut 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 la raison pour laquelle Perforce est toujours en activité après toutes ces années, c'est que les espaces de travail sont un moyen fantastique de réduire les projets de plusieurs millions de fichiers pour les développeurs tout en facilitant la création 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'elle 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 si nécessaire. De nombreuses entreprises organisent leur dépôt pour refléter l'organisation de leur entreprise afin qu'il soit facile pour les gens de trouver du contenu par unité commerciale ou par projet. Cependant, leur système de construction ne se soucie guère de cette hiérarchie; l'espace de travail leur permet de remapper leur hiérarchie de dépôt de la manière qui convient à leurs outils. J'ai également vu cela utilisé par des entreprises qui utilisent des systèmes de construction extrêmement rigides qui exigent que le code soit dans des configurations très spécifiques qui sont totalement déroutantes pour les humains. Les espaces de travail permettent à ces entreprises d'avoir une hiérarchie source qui est navigable par l'homme tandis que leurs outils de construction obtiennent la structure dont ils ont besoin.

Les espaces de travail dans Perforce ne sont pas seulement utilisés pour mapper l'ensemble de 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ées. 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 être un gain de performance considérable. Ceci est également très populaire dans les industries qui ont des règles d'audit très strictes; Les administrateurs Perforce peuvent facilement suivre et enregistrer quels développeurs ont synchronisé quels fichiers.

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

Paiement explicite et 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 travail Git / SVN / CVS consistant à modifier les fichiers et à dire au système de contrôle de version de rechercher ce que vous avez fait, cela peut être une transition extrêmement douloureuse.

La bonne nouvelle est que si vous le souhaitez, vous pouvez travailler avec 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 inscriptible défini. Vous pouvez ensuite modifier n'importe quel fichier de votre choix sans en informer explicitement Perforce. Pour que Perforce réconcilie les modifications que vous avez effectuées, vous pouvez exécuter "p4 status". Il ouvrira les fichiers à ajouter, modifier et supprimer le cas échéant. Lorsque vous travaillez de cette façon, vous voudrez utiliser "p4 update" au lieu de "p4 sync" pour obtenir de nouvelles révisions du serveur; "p4 update" vérifie les changements avant la synchronisation, donc n'effacera pas vos modifications locales si vous n'avez pas encore exécuté "p4 status".

Pourquoi un paiement explicite?

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

Une des raisons d'utiliser l'extraction explicite est qu'elle supprime la nécessité d'analyser les fichiers pour les modifications de contenu. Alors qu'avec des projets plus petits, calculer les hachages pour chaque fichier pour trouver des différences est assez bon marché, beaucoup de nos utilisateurs ont des millions de fichiers dans un espace de travail et / ou ont des fichiers d'une taille de 100 mégaoctets, sinon plus. Le calcul de tous les hachages dans ces cas prend beaucoup 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 grandes industries de fichiers comme les industries du jeu, du cinéma et du matériel.

Un autre avantage est que l'extraction explicite fournit une forme de communication asynchrone qui permet aux développeurs de savoir de manière générale sur quoi travaillent leurs pairs, ou du moins où. Il peut vous faire savoir que vous voudrez peut-être éviter de travailler dans un certain domaine afin d'éviter un conflit inutile, ou il peut vous alerter sur le fait qu'un nouveau développeur de l'équipe a erré dans un code dont il n'a peut-être pas besoin. être en train d’éditer. Mon expérience personnelle est que j'ai tendance à travailler soit dans Git, soit à utiliser Perforce avec allwrite sur des projets où je suis soit le seul contributeur, soit un contributeur peu fréquent, et le paiement explicite lorsque je travaille étroitement avec une équipe. Heureusement, le choix vous appartient.

La vérification explicite joue également bien avec le concept Perforce des 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 comme compartiments pour organiser le travail. Les branches sont excellentes, mais il est parfois agréable de pouvoir organiser votre travail en plusieurs changements nommés avant de le soumettre au serveur. Avec le modèle Perforce qui consiste à mapper potentiellement plusieurs branches ou plusieurs projets dans un seul espace de travail, les listes de modifications en attente facilitent l'organisation des modifications séparées.

Si vous utilisez un IDE pour le développement tel que Visual Studio ou Eclipse, je vous recommande vivement d'installer un plugin Perforce pour votre IDE. La plupart des plugins IDE extrairont automatiquement les fichiers lorsque vous commencerez à les éditer, vous évitant d'avoir à effectuer l'extraction vous-même.

Remplacements Perforce pour les fonctionnalités Git

• git stash ==> p4 shelve
• git local branching ==> soit des étagères Perforce, soit des branches de tâches
• git blame==> p4 annotateou Perforce Timelapse View à partir de l'interface graphique

Travail déconnecté

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

1) Utilisez P4Sandbox pour avoir une version locale complète et une branche locale

2) Modifiez les fichiers à votre guise et utilisez 'p4 status' pour dire à 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 que vous n'ayez pas à 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". "p4 update" vérifiera les fichiers pour les changements avant de les synchroniser.

Démarrage rapide de Perforce

Tous les exemples suivants se feront 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, les utiliser p4 setpour les enregistrer sous Windows et OS X, ou utiliser 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) Récupérez les fichiers du serveur

cd /Users/matt/work
p4 sync

3) Extrayez le fichier sur lequel vous souhaitez travailler et modifiez-le

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

4) Soumettez-le au serveur

p4 submit -d "A trivial edit"

5) Exécutez p4 help simplepour voir les commandes de base dont vous aurez besoin pour travailler avec Perforce.

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

• Dans git, l'abstraction est le patch (aka diff, aka changeset). Un commit dans git est essentiellement la sortie de l'exécution diffentre l'état précédent et actuel des fichiers en cours de validation .
• En effet, l'abstraction est le fichier . Un commit dans p4 est le contenu complet des fichiers dans le commit à ce moment-là. Ceci est organisé en 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 ensemble.

Tout le reste découle de cette différence . Le branchement et la fusion dans git sont indolores 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, et donc pour fusionner deux branches, il vous suffit d'appliquer tous les correctifs sur la branche source qui ne sont pas présents dans la branche cible vers la branche cible dans le bon ordre (en supposant qu'il n'y a pas de correctifs sur les deux branches qui se chevauchent).

Les branches Perforce sont différentes. Une opération de branche dans perforce copiera les fichiers d'un sous-dossier vers un autre, puis marquera le lien entre les fichiers avec des métadonnées sur le serveur. Pour fusionner un fichier d'une branche à une autre ( integrationen termes de force), perforce examinera le contenu complet du fichier en `` tête '' de sur la branche source et le contenu complet du fichier en tête de la branche cible et si nécessaire, fusionnez en utilisant un ancêtre commun. Il est incapable d'appliquer les correctifs un par un comme le peut git, ce qui signifie que les fusions manuelles se produisent plus souvent (et ont tendance à être plus douloureuses).

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 normalement considéré comme moins compliqué que les systèmes de contrôle de révision distribués modernes.

Essayer de mapper les 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. Exécutez p4 editsur chaque fichier que vous souhaitez modifier. Vous devez indiquer à Perforce les fichiers que vous modifiez. Si vous ajoutez de nouveaux fichiers, utilisez p4 add. Si vous supprimez des fichiers, utilisez p4 delete.
2. Modifiez votre code.
3. Exécutez p4 changepour créer un ensemble de modifications. Ici, vous pouvez créer une description de votre modification et éventuellement ajouter ou supprimer des fichiers de votre ensemble de modifications. Vous pouvez exécuter p4 change CHANGE_NUMBERpour modifier la description plus tard si nécessaire.
4. Vous pouvez apporter des modifications de code supplémentaires si nécessaire. Si vous devez ajouter / modifier / supprimer d'autres fichiers, vous pouvez utiliser p4 {add,edit,delete} -c CHANGE_NUMBER FILE.
5. Exécutez p4 syncpour extraire les dernières modifications du serveur.
6. Exécutez p4 resolvepour résoudre tous les conflits de synchronisation.
7. Lorsque vous êtes prêt à soumettre votre modification, exécutez p4 submit -c CHANGE_NUMBER.

Vous pouvez utiliser p4 revertpour annuler les modifications apportées aux fichiers.

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

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