web-dev-qa-db-fra.com

Comment l'intégration du contrôle de source Visual Studio avec Perforce?

Nous utilisons Perforce et Visual Studio. Chaque fois que nous créons une branche, certains projets ne seront pas liés au contrôle de code source à moins que nous n'utilisions "Ouvrir depuis le contrôle de code source", mais d'autres projets fonctionnent malgré tout. De mes investigations, je connais certaines des choses impliquées:

Dans nos fichiers .csproj, il y a ces paramètres:

  • <SccProjectName>
  • <SccLocalPath>
  • <SccAuxPath>
  • <SccProvider>

Parfois, ils sont tous définis sur "SAK", parfois non. Il semble que les choses soient plus susceptibles de fonctionner si elles disent "SAK".

Dans notre fichier .sln, il existe des paramètres pour de nombreux projets:

  • SccLocalPath #
  • SccProjectFilePathRelativizedFromConnection #
  • SccProjectUniqueName #

(Le # est un nombre qui identifie chaque projet.) SccLocalPath est un chemin d'accès relatif au fichier de solution. Souvent, c'est ".", Parfois c'est le dossier dans lequel se trouve le projet, et parfois c'est ".." ou "..\..", et il semble mauvais qu'il pointe vers un dossier au-dessus de la dossier de solution. Le relativisé est un chemin de ce dossier vers le fichier de projet. Il sera entièrement manquant si SccLocalPath pointe vers le dossier du projet. Si le SccLocalPath contient "..", ce chemin peut inclure des noms de dossiers qui ne sont pas les mêmes entre les branches, ce qui, je pense, cause des problèmes.

Donc, pour enfin arriver aux détails que j'aimerais savoir:

  • Que se passe-t-il lorsque vous modifiez le contrôle de code source et liez des projets? Comment Visual Studio décide-t-il ce qu'il faut mettre dans les fichiers de projet et de solution?
  • Que se passe-t-il lorsque vous faites "Ouvrir depuis le contrôle de code source"?
  • Quel est ce dossier de "connexion" auquel se réfèrent SccLocalPath et SccProjectFilePathRelativizedFromConnection? Comment Visual Studio/Perforce le choisit-il?
  • Existe-t-il un moyen recommandé de faire fonctionner les liaisons de contrôle de code source même lorsque vous créez une nouvelle branche de la solution?

Ajouté en juin 2012: Je n'utilise plus Perforce, donc je ne peux pas en témoigner, mais jetez un œil à KCD's réponse ci-dessous. Apparemment, il y a n nouveau plugin P4 VS en cours de développement. Espérons que cela devrait éclaircir tout ce gâchis!

visual-studioversion-controlperforce
71
Weeble

Introduction

Je ne suis pas d'accord avec l'affirmation selon laquelle l'intégration de Perforce dans Visual Studio est "terrible". Au contraire, je le définirais comme "une expérience prête à l'emploi est loin d'être optimale" :-). Les sections suivantes discutent de ma compréhension de l'intégration et des recommandations pour la configuration du projet/de la solution.

Si vous n'êtes pas intéressé par les détails du fonctionnement de l'intégration du contrôle de code source, vous pouvez passer à la fin de cette réponse où je résume les réponses à la question de Weeble.

Avis de non-responsabilité : Les sections suivantes ne sont que des suppositions éclairées basées sur mon expérience empirique, mais j'ai utilisé la technique pendant de nombreuses années dans de nombreux projets (chaque projet ayant plusieurs branches expérimentales/trunk/maintenance/release, parfois même plusieurs fichiers de solution, sans problèmes). L'inconvénient est que vous devez manuellement mettre à jour les fichiers du projet - mais l'investissement de 2 minutes est amorti assez bien sur la durée de vie d'un projet à mon humble avis :-) .

Solution vs projet

Visual Studio utilise les informations de liaison de contrôle de source à la fois du fichier de solution et de chaque fichier de projet lors du chargement initial de la solution. Ces informations de liaison sont ensuite stockées dans le fichier name.suo (en supposant que nous utilisons name.sln comme solution) - notez que les fichiers suo sont marqués avec l'indicateur caché afin qu'ils ne soient pas visibles dans l'Explorateur de fichiers (sauf si vous remplacez l'option "Fichiers et dossiers cachés").

Le moyen le plus simple de se reconnecter au fournisseur de contrôle de code source en cas de problème est de supprimer le fichier suo approprié et de rouvrir la solution. Une fois le fichier suo créé, les modifications apportées aux éléments <Scc *> n'ont aucun effet.

Si, lors de l'ouverture initiale de la solution, il existe une différence entre les informations de liaison stockées dans le fichier de solution et les informations stockées dans le fichier de projet, Visual Studio tentera de résoudre ce problème (parfois, il vous demandera même de décider si les informations dans la solution ou les informations du projet doivent être utilisées comme "maître" pour résoudre la divergence):

alt text

Pourquoi Visual Studio viole-t-il le principe DRY (Don't Repeat Yourself)? Je n'en ai aucune idée. Je suppose que cela a des raisons historiques et est étroitement lié aux besoins de ce cauchemar appelé Visual Source Safe: -).

Comment le configurer "correctement"?

Lors de l'ajout de solutions/projets nouveaux ou existants à Perforce, je toujours commence par créer une solution vierge (voir la section "Contrôle à la source d'une solution vierge"). J'ajoute ensuite des projets à cette solution vierge, l'un après l'autre. Les étapes diffèrent légèrement selon que le projet ajouté existe déjà (voir les sections "Contrôle de source des projets existants (non liés)" et "Contrôle de source des projets existants (liés)") ou si je dois en créer un nouveau (voir le Section "Contrôle des sources de nouveaux projets").

Contrôle à la source d'une solution vierge

Pour ajouter une nouvelle solution vierge au contrôle de code source, procédez comme suit:

  1. Démarrez Visual Studio, "Nouveau" -> "Projet ..." -> "Autres types de projets" -> "Solution vide"; remplir le nom et l'emplacement de la solution, bouton "OK"
  2. "Fichier" -> "Contrôle source" -> "Ajouter une solution au contrôle source ..."
  3. Dans la boîte de dialogue de connexion, entrez le port de serveur P4, le client et l'utilisateur appropriés (notez que la vue du client sélectionné doit inclure l'emplacement que vous avez choisi à l'étape 1)
  4. "Afficher" -> "Archivages en attente" -> "Archiver" -> dans la boîte de dialogue de soumission au lieu d'appuyer sur le bouton "Soumettre", utilisez "Annuler".
    Reason: L'action "Check In" créera un nouveau fichier, "name.vssscc", puis ajoutera "name.sln" et "name.vssscc" à la liste des modifications par défaut de Perforce ; en annulant la boîte de dialogue de soumission, nous garderons l'opération "ajouter" en attente et nous pourrons modifier les fichiers avant de les soumettre à P4
  5. Fermez Visual Studio

  6. Ouvrez le fichier name.sln dans votre éditeur préféré (bloc-notes, si vous êtes vraiment désespéré :-)) et ajoutez deux nouvelles lignes (SccProjectName et SccProvider) - le blanc Le fichier de solution devrait maintenant avoir une section de contrôle de source comme suit:

    GlobalSection(SourceCodeControl) = preSolution
    SccNumberOfProjects = 1
    SccLocalPath0 = .
    SccProjectName0 = Tutorial
    SccProvider0 = MSSCCI:Perforce\u0020SCM
EndGlobalSection

    Les valeurs doivent être choisies comme suit:

    • SccProjectName: une chaîne arbitraire qui sera affichée dans la boîte de dialogue "Change Source Control" comme "Server Binding". Ce nom est utilisé pour déterminer quels projets/fichiers de solution peuvent partager la même connexion de contrôle de source. Je recommande de ne pas utiliser d'espace pour ce nom car les règles d'échappement pour les espaces sont différentes dans les fichiers de solution et de projet.
    • SccProvider: valeur codée en dur "MSSCCI: Perforce\u0020SCM".
  7. Soumettez les deux fichiers en attente à l'aide du client Perforce de votre choix (p4.exe, P4Win, P4V)

Vous pouvez maintenant tester les liaisons:

  1. Assurez-vous que Visual Studio est fermé
  2. Supprimez ** tous * les fichiers sauf le nom.sln (en particulier le nom.suo)
  3. Ouvrez Visual Studio et utilisez-le pour ouvrir name.sln
  4. Une boîte de dialogue de connexion doit apparaître, utilisez le port/client/utilisateur approprié et cliquez sur OK
  5. L'Explorateur de solutions doit maintenant afficher le nœud de solution avec une icône de superposition de cadenas: Source-controlled blank solution
  6. Vous pouvez maintenant vérifier l'état du contrôle de source de la solution en utilisant "Fichier" -> "Contrôle de source" -> "Modifier le contrôle de source ...": Source control status of blank solution Remarque: La colonne "Liaison du serveur" affiche la valeur que nous avons choisie pour "SccProjectName0".

Nouveaux projets avec contrôle des sources

Si vous créez un tout nouveau projet et que vous souhaitez immédiatement commencer à le suivre dans un dépôt Perforce, procédez comme suit:

  1. Ouvrez la solution contrôlée par la source dans Visual Studio
  2. "Fichier" -> "Ajouter" -> "Nouveau projet ..." - choisissez le type de projet que vous ajoutez, le nom et l'emplacement (l'emplacement doit être un sous-répertoire du répertoire où le fichier de solution est stocké)
  3. "Fichier" -> "Enregistrer tout" (cela va valider toutes les modifications en mémoire dans le fichier de solution et le fichier de projet nouvellement créé sur le disque)

  4. Modifiez manuellement le fichier de projet que vous venez de créer à l'aide d'un éditeur de votre choix (allez, bloc-notes ENCORE? ;-)). Ajoutez les éléments de propriété suivants dans un PropertyGroup (tout groupe de propriétés):

    <PropertyGroup>
    ...
    <SccProjectName>Tutorial</SccProjectName>
    <SccLocalPath>..\..</SccLocalPath>
    <SccProvider>MSSCCI:Perforce SCM</SccProvider>
    ...
</PropertyGroup>

    Les valeurs doivent être choisies comme suit:

    • SccProjectName - c'est la valeur qui est affichée dans la boîte de dialogue "Change Source Control" comme "Server Binding"; doit être identique à la valeur que vous avez utilisée pour SccProjectName0 dans une solution vide; sinon, la solution et ce projet ne pourront pas partager la même connexion de fournisseur de contrôle de source
    • SccLocalPath - chemin relatif vers le répertoire de référence (affiché dans la boîte de dialogue "Change Source Control" comme "Local binding"); car je recommande d'utiliser le répertoire de la solution comme répertoire de référence, il s'agit en fait du chemin relatif du répertoire contenant le fichier de projet au répertoire contenant le fichier de solution (mon exemple stocke des projets dans "(solutionDir) /Source/ProjectName/projectName.csproj", donc le chemin relatif est "deux niveaux plus haut")
    • SccProvider - valeur codée en dur "MSSCCI: Perforce SCM"; ceci est utilisé pour déterminer quels fournisseurs SCCAPI sont les valeurs de liaison Scc * valides pour

  5. Revenez à Visual Studio; il devrait détecter automatiquement que le fichier de projet a été mis à jour en externe et proposer de le recharger (sinon, décharger et recharger le projet manuellement)

  6. "Affichage" -> "Archivages en attente"
  7. "Archiver" -> Je recommande de cliquer avec le bouton droit sur le fichier (solutionName) .vssscc et de sélectionner "Rétablir si inchangé" (même si Visual Studio l'ouvre pour modification, il reste inchangé); fournir une description et soumettre la modification

Pour vérifier que le projet nouvellement ajouté est correctement lié, vous pouvez suivre ces étapes:

  1. Assurez-vous que Visual Studio est fermé
  2. Supprimez le fichier (solutionName) .suo ainsi que MSSCCPRJ.SCC (dans le répertoire de la solution)
  3. Ouvrez Visual Studio et utilisez-le pour ouvrir (solutionName) .sln
  4. Une boîte de dialogue de connexion doit apparaître, utilisez le port/client/utilisateur approprié et cliquez sur OK
  5. L'Explorateur de solutions doit maintenant afficher le nœud du projet avec une icône de superposition de cadenas: Source-controlled projects

  6. Vous pouvez maintenant vérifier l'état du contrôle de source de la solution en utilisant "Fichier" -> "Contrôle de source" -> "Modifier le contrôle de source ...": Status of source-controlled projects

    Une chose à noter à propos de cette capture d'écran d'état est que lorsque j'ai sélectionné la ligne de solution, toutes les lignes restantes ont également été "sélectionnées" (surbrillance bleue). Cela est dû au fait que toutes ces entrées ont la même "liaison serveur" + "liaison locale" et partagent ainsi la même connexion P4 (source-control-provider).

    Notez également que le "Chemin relatif" pour les deux projets a deux niveaux et est relatif au même "Liaison locale" - le répertoire où réside le fichier de solution.

Projets existants (non liés) de contrôle des sources

Si vous avez des projets existants qui n'ont pas encore été utilisés dans une autre solution Perforce, procédez comme suit pour les ajouter à Perforce (c'est-à-dire importer des projets qui n'ont pas été contrôlés par la source auparavant (téléchargements Internet, etc.) ou utilisiez un contrôle de source différent fournisseur (Visual Source Safe, etc.).

  1. Copiez le projet dans l'emplacement approprié
  2. Nettoyer les liaisons de contrôle de source existantes (le cas échéant):
    • Supprimez les liaisons de fichiers de projet existantes, c'est-à-dire toutes les propriétés commençant par "Scc"
    • Supprimer le fichier (projectName) .vspscc dans le même répertoire que le fichier de projet (le cas échéant)
  3. Ouvrez la solution contrôlée par la source dans Visual Studio
  4. "Fichier" -> "Ajouter" -> "Projet existant ..." - recherchez le projet (la copie que vous avez créée à l'étape 1)
  5. "Fichier" -> "Enregistrer tout" (cela va valider toutes les modifications en mémoire dans le fichier de solution)
  6. Suivez les étapes 4 à 7 de "Nouveaux projets de contrôle de source" (c'est-à-dire que vous allez maintenant ajouter des éléments de propriété "Scc *" dans un PropertyGroup)

Les étapes de vérification sont exactement les mêmes que dans la section "Contrôle de source de nouveaux projets".

Projets existants (liés) de contrôle de la source

Si vous avez des projets qui ont déjà été liés à Perforce en utilisant la technique décrite ici et que vous souhaitez les utiliser dans une solution différente (nouvelle branche, solution alternative réutilisant le projet, etc.), procédez comme suit:

  1. Intégrez le projet à l'emplacement souhaité
  2. Ouvrez la solution contrôlée par la source dans Visual Studio
  3. "Fichier" -> "Ajouter" -> "Projet existant ..." - accédez au projet créé à l'étape 1 via l'intégration
  4. "Afficher" -> "Archivages en attente" -> "Archiver" - ajouter une description et soumettre

Sommaire

  • Les informations de liaison du contrôle de code source sont stockées dans la solution et les projets, doivent être synchronisées (sinon, Visual Studio tentera de corriger les écarts)
  • Je traite toujours les fichiers de projet comme la principale source d'informations de liaison et les fichiers de solution comme des fichiers jetables qui peuvent être recréés facilement en contrôlant d'abord une solution vierge puis en ajoutant les projets souhaités
  • Le fichier de solution doit toujours avoir des valeurs SccProvider et SccProjectName valides (doivent être ajoutées manuellement avec les nouvelles versions des plug-ins P4SCC)
  • Les fichiers de projet doivent toujours avoir des valeurs SccProjectName (de préférence identiques à SccProjectName), SccLocalPath et SccProvider (doivent également être modifié manuellement car les valeurs par défaut du P4SCC ne sont pas bonnes)

J'inclus également des réponses à vos questions originales:

Que se passe-t-il lorsque vous modifiez le contrôle de code source et liez des projets? Comment Visual Studio décide-t-il ce qu'il faut mettre dans les fichiers de projet et de solution?

Cela met à jour les éléments "Scc *" dans un fichier de projet que vous reliez; le fichier de solution est ensuite également mis à jour afin qu'il soit synchronisé avec les liaisons de fichier de projet

Que se passe-t-il lorsque vous faites "Ouvrir depuis le contrôle de code source"?

Vous permet de choisir la solution que vous souhaitez ouvrir. Ensuite, tous les projets inclus dans la solution sont automatiquement synchronisés avec head. Je trouve que cette fonctionnalité n'est pas très utile dans le monde Perforce où vous devez de toute façon créer un client et il y a de fortes chances que vous synchronisiez ce client à partir d'un P4V/P4Win/P4 au lieu de compter sur Visual Studio. Cela était plutôt utile dans le monde Visual Source Safe où il n'y avait pas de concept de vues et où vous définissiez où va un référentiel au moment du paiement.

Quel est ce dossier de "connexion" auquel se réfèrent SccLocalPath et SccProjectFilePathRelativizedFromConnection? Comment Visual Studio/Perforce le choisit-il?

Il s'agit de la comptabilité de Visual Studio. Il est déterminé en fonction des liaisons dans chaque fichier de projet (je suppose qu'en théorie, si un fichier de projet perd des informations de liaison pour une raison quelconque, il pourrait être reconstruit à partir des informations de la solution ...)

Existe-t-il un moyen recommandé de faire fonctionner les liaisons de contrôle de code source même lorsque vous créez une nouvelle branche de la solution?

J'espère que les sections ci-dessus vous donnent une idée d'une méthode qui fonctionne très bien pour moi :-).

102
Milan Gardian

Le poste de Milan est bien documenté et bien écrit, mais sa longueur démontre sans l'ombre d'un doute que le modèle P4SCC est cassé. Stocker des informations de liaison de contrôle de source dans les fichiers de projet et de solution est ridicule. Appliquer (via sccprojectname) qu'un projet fasse partie d'une seule solution est tout aussi ridicule.

De plus, P4SCC a un coût de performance énorme dans une grande solution, car il récupère les informations du contrôle de source pour chaque fichier au démarrage et maintient cet état en mémoire tout au long de la session de développement. Il crée une cruauté supplémentaire sous forme de fichiers .vsscc et vssscc sans information pour prendre en charge certaines fonctionnalités SCC que (AFAICT) Perforce n'utilise pas.

L'intégration idéale de Perforce ressemble à:

  • Si je crée une nouvelle solution, un projet ou un élément de projet, exécutez 'p4 add'.
  • Si je change un fichier, lancez "p4 edit".
  • Intégration de la barre d'outils/du menu contextuel pour l'historique des révisions, le graphique des révisions, le timelapse/blame et "afficher dans P4 gui".
  • (C'est bien d'avoir) Si je renomme un fichier qui existe dans le dépôt, exécutez 'p4 integrer' et 'p4 delete'. Si je renomme un fichier ouvert pour l'ajout, exécutez 'p4 revert' et 'p4 add'.
  • C'est tout

Nous nous sommes complètement éloignés du P4SCC et de ses exigences et charges bizarres. Au lieu de cela, nous utilisons NiftyPerforce . Il existe quelques bogues, mais nous trouvons que contourner ces bogues est beaucoup moins frustrant que de contourner les défauts de conception dans le modèle Perforce <-> VSSCC.

22
Timbo

Juste pour garder ce courant - le plugin P4VS a été réécrit vers 2012

Vous pouvez désormais effectuer naturellement toutes vos interactions quotidiennes avec Perforce, comme archiver du code et afficher l'historique des fichiers, directement depuis l'EDI.

Si vous êtes un utilisateur expérimenté qui en recherche un peu plus, P4VS ne vous décevra pas. P4VS est entièrement compatible avec Perforce Streams, et le graphique de flux est accessible à partir de l'EDI, ainsi que la vue en accéléré et le graphique de révision. Si vous êtes responsable de la gestion des succursales, vous pouvez également fusionner à partir de P4VS.

Et, si vous travaillez à distance ou si vous souhaitez effectuer un petit branchement privé, P4Sandbox peut être configuré via P4VS.

9
KCD

L'utilisation de Perforce avec Visual Studio peut être simplifiée en utilisant la variable d'environnement P4CONFIG.

Fondamentalement, vous allez dans Visual Studio, Outils -> Options -> Contrôle de source -> Paramètres du plug-in, bouton Avancé. Cela fera apparaître une boîte de dialogue de configuration Perforce spécifique à l'intégration SCC. Basculez vers l'onglet Connexion et cochez la case d'option intitulée "Lier l'espace de travail qui correspond à vos paramètres d'environnement Perforce". Cela indiquera forcer à préférer utiliser la variable d'environnement P4CONFIG pour déterminer l'environnement dans lequel vous vous trouvez. Cette même boîte de dialogue existe dans P4V sous Edition -> Préférences, mais n'affecte que le comportement de p4v.

La façon dont vous configurez la variable d'environnement P4CONFIG dépend de vous dans une certaine mesure. J'aime qu'ils soient nommés de la même manière partout, alors j'ai défini une variable d'environnement à l'échelle du système P4CONFIG pour rechercher un fichier nommé p4config.cfg. Ce fichier est juste un fichier de style ini, où vous pouvez assigner d'autres variables telles que P4USER, P4CLIENT, P4Host etc. Perforce recherchera ce fichier dans le répertoire courant et tous les répertoires parents jusqu'à ce qu'il en rencontre un. Fondamentalement, vous placez ce fichier dans le répertoire racine le plus de votre où votre clientpec est mappé sur votre disque dur, et le laissez tranquille.

Cette approche réduit considérablement le degré de "correction" dont a besoin la configuration SCC dans Visual Studio pour fonctionner. (Les liaisons SAK fonctionnent correctement, etc.)

Si après avoir synchronisé votre code depuis perforce pour la première fois ou vers une structure de répertoires totalement propre, et avoir obtenu une boîte de dialogue se plaignant que perforce souhaitait travailler temporairement hors ligne ou supprimer des liaisons, il y avait encore quelques modifications à faire. Principalement, le fichier .sln lui-même doit être modifié afin qu'il sache que le sln a des liaisons SCC pour lui-même. Cela est fait en s'assurant que les champs suivants sont placés juste après SccNumberOfProjects dans le fichier .sln.

SccProjectName0 = Perforce\u0020Project
SccProvider0 = MSSCCI:Perforce\u0020SCM

Tous les projets individuels devraient fonctionner correctement avec les "liaisons SAK" par défaut à condition que vous utilisiez l'approche P4CONFIG. La résolution de ce problème devrait permettre à Perforce de fonctionner parfaitement à partir d'une synchronisation propre et d'éliminer également la génération de fichiers MSSCCPRJ.SCC dans chacun des répertoires du projet.

5
Zoner

La prise en charge de renommer un fichier ou de le déplacer vers un nouveau répertoire de dossiers est terrible et douloureuse si vous utilisez l'intégration du plug-in Visual Studio P4. Il n'existe aucune fonction intégrée qui avertit P4 de renommer le fichier ou qu'il a été déplacé.

Le problème est que le changement de nom d'un fichier nécessite non seulement la mise à jour du fichier de projet VS associé, mais Perforce doit également être informé de la modification si vous souhaitez conserver un historique de révision correct.

Actuellement, je ne vois pas de moyen de faire les deux en une seule opération si vous utilisez l'intégration VS. Au lieu de cela, vous devez:

  1. renommer/déplacer le fichier depuis le client Perforce
  2. supprimer l'ancienne référence de nom de fichier dans le fichier de projet dans VS
  3. ajouter la nouvelle référence de nom de fichier dans le fichier de projet dans VS
  4. soumettre vos modifications

Si vous utilisez un processus de génération d'intégration continue et que vous soumettez des modifications à tout moment avant la dernière étape, vous êtes assuré d'avoir une génération interrompue.

Le problème s'agrandit considérablement lorsque plus de fichiers nécessitent un changement de nom ou un déplacement. Ce n'est pas du tout un processus fluide.

4
Ray Vega

Après avoir expérimenté avec la réponse très informative de Milan Gardian, je pense que je peux fournir une solution plus simple pour le faire fonctionner assez bien.

Comme Weeble l'a mentionné, les valeurs SAK fonctionnent bien lorsque tout le reste est correctement configuré, et ce sont souvent les valeurs par défaut (mais je pense que cela dépend de quel type de projet il s'agit). S'ils n'apparaissent pas dans votre projet, collez simplement ce groupe de propriétés.

<PropertyGroup>
    <SccProjectName>SAK</SccProjectName>
    <SccProvider>SAK</SccProvider>
    <SccAuxPath>SAK</SccAuxPath>
    <SccLocalPath>SAK</SccLocalPath>
</PropertyGroup>

Ajoutez ces deux lignes au * .sln dans la SourceCodeControl GlobalSection. Tant que les fichiers de projet ont des valeurs SAK, ils doivent hériter des noms de la solution.

SccProjectName0 = Perforce\u0020Project
SccProvider0 = MSSCCI:Perforce\u0020SCM

Aucun fichier * .vssscc, * .vspscc ou * .SCC ne doit être archivé (bien qu'il soit généré à l'ouverture de la solution).

3
Dave Andersen

Très pauvrement. Je sais que ce n'est pas la réponse à vos questions que vous cherchiez (à l'avenir, vous pourriez peut-être affiner le focus?), Mais l'intégration du contrôle de source avec Visual Studio est tout simplement nulle. La raison étant qu'ils doivent tous utiliser la terrible interface SCC de Microsoft. C'est pathétique! Ils ont mis les informations de contrôle des sources dans les fichiers du projet! Pourquoi feraient-ils cela?

Abandonnez simplement l'intégration de Visual Studio et utilisez le client Perforce. Ce n'est pas beaucoup de travail supplémentaire. Vous ne pouvez pas ménager 30 secondes par jour pour passer au client Perforce et archiver/extraire les fichiers à partir de là?

2
raven

Je peux répondre à la dernière.

Afin de faire fonctionner les liaisons de contrôle de code source même lorsque vous créez une nouvelle branche, suivez une structure hiérarchique stricte:

/Solution
  /library1
  /library2
  /product1
  /product2
  /subsolution
    /sublibrary1
    /subproduct1

Chaque fichier doit être dans exactement un .vcproj. Vous pouvez avoir plusieurs .vcproj dans le même répertoire, mais s'ils partagent des fichiers, les fichiers partagés doivent aller dans leur propre .vcproj.

Si vous êtes implacable dans tout cela, tous les trucs Scc seront relatifs-path, donc une nouvelle branche fonctionnera (car elle ne change que le répertoire le plus haut).

1
Thomas L Holaday