J'utilise Visual Studio 2010 Pro contre Team Server 2010 et mon projet a été ouvert (apparemment) comme solution du référentiel, mais j'aurais dû l'ouvrir en tant que "site Web". Je l'ai découvert lors de la compilation. Je suis donc allé classer mes nouvelles modifications, j'ai supprimé le projet de mon disque local, puis j'ai rouvert le projet à partir du code source (cette fois en tant que site Web). Je ne peux plus décompresser mes fichiers.
Est-il possible de contourner ce problème? Ai-je fait sauter quelque chose? Dois-je effectuer une maintenance sur le serveur?
J'ai trouvé cette question sur SO # 2332685 mais je ne sais pas de quels fichiers cache il parle (je suis sur XP: \) EDIT: Trouvé ceci lien après avoir posté la question, désolé pour le retard dans la recherche, n'a toujours pas résolu mon problème
Bien sûr, je ne trouve aucun code d'erreur pour TF203015, donc pas de résolution non plus (d'où mon inclusion du numéro dans le titre, oui?)
EDIT: Je devrais probablement mentionner que ces fichiers n’ont jamais été archivés. Est-ce important? Pouvez-vous ranger un article non vérifié? Est-ce ce que j'ai mal fait?
EDIT: WHAP - TROUVEZ-LE !!! Utilisez "Annuler" sur les éléments qui n'existent pas car ils apparaissent dans les modifications en attente en tant que checkins.
J'avais supprimé les fichiers en essayant de recharger l'espace de travail, même si j'avais mis les modifications en suspens. Ensuite, VS2010 a pensé que ces fichiers étaient toujours en attente de sauvegarde. Je n'avais pas besoin de ça, alors j'ai dû trouver pour "annuler" les modifications dans les modifications en attente.
Ensuite, je pourrais me défaire.
Il pensait que j'avais deux opérations (unshelve, commit-for-add) simultanément, et je pensais n'en avoir qu'un (unshelve).
Ceci est un léger aparté à la question du PO
Vous pouvez obtenir un TF203015 lorsque vous essayez de fusionner par lots plusieurs ensembles de modifications d’une branche à l’autre sans précaution.
Prenons une situation où vous avez une ligne principale MAIN et une branche DEV. Vous avez créé DEV auprès de MAIN et avez travaillé avec diligence sur une fonctionnalité de DEV; vérification du travail dans DEV au fur et à mesure de votre progression. Maintenant avance rapide d'une semaine ou deux. Vous avez maintenant terminé la fonctionnalité et souhaitez fusionner dans MAIN.
C'est là que l'un de nos développeurs a frappé cette erreur.
Cela faisait des semaines qu'il travaillait sur une solution et vérifiait périodiquement les ensembles de modifications dans DEV. Il souhaitait donc fusionner une série non modifiée de modifications dans MAIN . fusionne sans problème, puis est immédiatement allé fusionner le prochain changeset; et bang TF203015, et son test très inutile dans la fenêtre de sortie; modifications en attente incompatibles.
Après un peu de tripotage, nous réalisons maintenant ce qui se passe ici; la première fusion a créé une modification en attente dans MAIN pour la solution des développeurs. La tentative de fusion suivante consistait également à modifier la même solution, ce qui nécessiterait que TFS mette en file d'attente un deuxième ensemble de modifications en attente dans les mêmes fichiers. Il ne peut pas faire ça.
Donc, dans ce scénario, TF203015 signifie; "La branche de destination a déjà des modifications en attente sur certains fichiers qui sont modifiés dans cet ensemble de modifications. Veuillez résoudre et valider les modifications de la branche de destination avant d'effectuer cette opération de fusion"
La solution; après chaque opération de fusion, notre développeur teste l'espace de travail pour MAIN et valide la modification en attente provoquée par la fusion, puis revient à DEV et répète.
En réalité sensible et simple, mais masqué par un message d'erreur très obtus.
Vous pouvez utiliser les outils puissants de Team Foundation Server mars 2011 ( http://msdn.Microsoft.com/en-us/vstudio/bb980963.aspx ) qui inclut la commande tfpt unshelve
.
Une fois les outils puissants installés, ouvrez une invite de commande Visual Studio, accédez au répertoire contenant le projet qui vous intéresse et exécutez la commande tfpt unshelve
. Cela affichera la boîte de dialogue de fusion et vous permettra de résoudre les conflits.
Je reconnais que ce billet de blog m'aide à trouver cette solution: http://fluentbytes.com/the-how-and-why-behind-tf203015-file-has-an-incomponable-change-while-unshelving-a- shelve-set
J'avais ce qui semblait être le même problème, mais j'avais créé une branche après avoir mis de côté mes modifications et je voulais annuler ces modifications dans la nouvelle branche.
TFS ne peut pas accéder à un chemin différent du chemin sur lequel l'étagère a été créée.
Solution: Je suis revenu à la branche d'origine, puis je l'ai utilisé au-delà de la comparaison pour fusionner les modifications de ma branche d'origine vers la nouvelle branche.
Il se peut également que, après avoir créé un dossier dans un "Test" et que vous souhaitiez fusionner de dev à test, la structure de dossiers nouvellement créée ne soit pas archivée dans TFS. Vous obtiendrez/pourrez également obtenir ce message d'erreur.
Ainsi, ce message d'erreur PEUT se produire sans rien avoir à faire avec SHELVESETS ni pour les autres utilisateurs de Google et pour la recherche de cette page.
C’est peut-être la même chose que la réponse de jcolebrand, mais je crains d’avoir trouvé le libellé un peu abstrus. Toutes mes excuses si je ne fais que répéter.
Dans mon scénario, le message incompatible pending change
a été présenté parce que j'essayais de restaurer plusieurs ensembles de modifications et que le même fichier était affecté par plusieurs de ces ensembles de modifications.
Dans mon cas, je ne voulais pas m'engager avant que toutes les modifications aient été annulées. Je crois que si j'avais pu valider après avoir annulé chaque jeu de modifications, l'erreur ne serait pas survenue.
La méthode qui a fonctionné pour moi était la suivante:
incompatible pending change
, je devais annuler les modifications en attente de mon espace de travail pour les fichiers affectés.incompatible pending change
. Généralement, ceci pourrait être obtenu simplement en obtenant une version spécifique du fichier (la version "dernier-connu-bon" avant le début de toutes les vérifications erronées). Mais pour certains fichiers où il y avait eu à la fois les modifications souhaitées et les modifications non souhaitées, j'ai obtenu le «bon dernier connu» et appliqué manuellement les modifications correctes.Si vous avez deux branches MAIN (cible) et DEV (source), vous souhaitez maintenant fusionner DEV dans MAIN. Tous les fichiers à fusionner depuis votre source ne doivent pas être plus anciens que les fichiers similaires de votre branche cible.
Par exemple: vous avez un fichier modifié test.cs dans votre branche DEV, modifié le 14.03.2016. Dans votre branche MAIN, test.cs a été modifié le 15.03.2016. La cible est donc plus récente que le fichier source et vous avez TF203015.
Solution: naviguer dans l'explorateur TFS jusqu'au fichier de conflit et le fusionner explicitement. TFS ouvrira le gestionnaire de conflit et vous pourrez fusionner les conflits à la main. Vous pouvez ensuite fusionner le jeu de modifications sélectionné.
Remarques: Si vous avez plus de conflits, vous devez accéder à chaque fichier de conflit et le fusionner de manière explicite. TFS ouvre donc le gestionnaire de conflit et vous pouvez le fusionner à la main.
Ce lien a résolu mon problème:
La raison en attente de modification dans le même espace de travail crée une modification incompatible. Alors annulez les modifications en attente et essayez de décompresser. Cela devrait résoudre le problème.