Question

Si j'ai créé une étiquette dans TFS en l'attribuant à plusieurs fichiers, mes collègues ne peuvent pas modifier les versions des fichiers (ni en ajouter d'autres) à cette étiquette. Nous avons cette erreur:

TF14077: The owner of a label cannot be changed. 

À la recherche du problème, j’ai trouvé cet article , qui indique:

  

Il est possible qu'un utilisateur soit   autorisé à manipuler une étiquette partagée   dans le dossier de développement mais seulement   manipuler les étiquettes qu'ils possèdent dans un   dossier de production.   (c'est moi qui souligne)

Malgré tous mes efforts, je ne trouve aucune référence aux "étiquettes partagées". Autant que je sache, une étiquette doit avoir un propriétaire.

FWIW, ce que j'essaie de faire est d’utiliser un "flottant" label afin que les développeurs puissent indiquer que leur code est prêt à faire partie de la construction en le taggant avec une étiquette particulière. Ensuite, le processus de construction aurait juste besoin de tout obtenir avec cette étiquette, et d'obtenir automatiquement les éléments les plus récents qui sont réellement prêts à être construits, en ignorant les versions antérieures ainsi que les éléments plus récents qui ne sont pas prêts pour le prime time.

Mise à jour: Je suppose que si je ne peux pas créer une étiquette vraiment partagée, je peux au moins donner aux utilisateurs le droit de modifier les étiquettes créées par leurs collègues. C'est assez explicitement supporté. Les utilisateurs habituels Contributor n'ont pas ce droit, mais selon MSDN (voir l'article Autorisations de Team Foundation Server , sous Autorisations de contrôle de la source ), il peut être accordé via l'autorisation LabelOther :

  

Les autorisations de contrôle de source sont   spécifique aux fichiers de code source et   Dossiers. Vous pouvez définir ces autorisations   en faisant un clic droit sur le dossier ou le fichier   dans l'Explorateur de contrôles source, en cliquant sur   Propriétés, et sur l'onglet Sécurité,   sélectionner l'utilisateur ou le groupe pour lequel   vous souhaitez modifier les autorisations, et   puis éditer les permissions listées dans   Autorisations Vous pouvez définir ces   autorisations en utilisant le tf   utilitaire de ligne de commande pour la source   contrôle.

...

  

Administrer les étiquettes | tf: LabelOther | Les utilisateurs disposant de cette autorisation peuvent modifier ou supprimer les étiquettes créées par un autre utilisateur.

J'ai donc attribué ce droit au groupe de domaines contenant tous les développeurs, comme suggéré ci-dessus. Je peux vérifier qu'il est défini à l'aide de la commande autorisation tf :

tf permission /group:"CORP\Web Team"

et le résultat est celui attendu (j'ai également attribué une étiquette, juste pour le fun)

===============================================================================
Server item: $/Test1/TeamBuildTypes (Inherit: Yes)
  Identity: CORP\Web Team
    Allow:
    Deny:
    Allow (Inherited): Label, LabelOther
    Deny (Inherited):

Pourtant, mon utilisateur de test n'est toujours pas autorisé à modifier l'étiquette que j'ai créée.

Était-ce utile?

La solution 2

Je n'ai jamais réussi à faire fonctionner ce travail avec des étiquettes. Au lieu de cela, nous avons mis au point un processus complètement différent en utilisant la création de branches, ce que je recommande maintenant vivement à toute personne qui lit ceci.

Nous avons mis en place un schéma de branchement de manière à créer une branche de développement générale; à partir de là, chaque développeur a sa propre branche avec laquelle il peut faire ce qu'il veut, et il y a une branche Production.

  • Les développeurs font leur "sale" " travaillent dans leur branche privée sans craindre de libérer accidentellement des choses, ni même d'interférer avec leurs collègues.
  • Lorsqu'ils ont quelque chose de prêt à intégrer, ils fusionnent les modifications dans la branche de développement. Nous y construisons en continu et testons les résultats.
  • Lorsqu'une version intégrée est entièrement testée et prête à être déployée, les modifications sont fusionnées dans la branche Production. Ceci est construit et déployé.

J'avais dit que je voulais

  

ce que j'essaie de faire est d'employer un   " flottant " étiquette afin que les développeurs   peut indiquer que leur code est prêt   faire partie de la construction en marquant   avec une étiquette particulière.

Le schéma que j'ai décrit ci-dessus répond pleinement à cet objectif, et plus encore.

Autres conseils

Les ensembles de tablettes seraient-ils une meilleure solution pour ce que vous faites? IIRC dispose d’une API assez riche pour travailler avec des ensembles de tablettes, tels que leur validation dans le cadre d’un processus de construction (ou autre).

J'ai trouvé les étiquettes dans TFS très limitées lorsque je les utilisais.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top