Делитесь ярлыками в TFS?

Если я создал метку в TFS, назначив ее нескольким файлам, мои коллеги не смогут изменить версии файлов (или добавить другие файлы) к этой метке. Получаем такую ​​ошибку:

TF14077: The owner of a label cannot be changed.

Изучая проблему, я нашел эту статью, в которой говорится:

Возможно, пользователю будет разрешено манипулировать общей меткой в папке разработки, но управлять только собственными метками в производственной папке. (курсив мой)

Как я ни старался, я не могу найти ни одной ссылки на "общие ярлыки". Насколько я понимаю, у лейбла должен быть владелец.

FWIW, я пытаюсь использовать «плавающую» метку, чтобы разработчики могли указать, что их код готов стать частью сборки, пометив ее определенной меткой. Тогда в процессе сборки просто нужно будет получить все, что имеет этот ярлык, и автоматически получить самые последние материалы, которые действительно готовы к сборке, игнорируя как прошлые версии, так и более новые вещи, которые не готовы к использованию в прайм-тайм.

Обновление: я полагаю, что если я не могу создать действительно общий ярлык, я могу хотя бы дать пользователям право редактировать ярлыки, созданные их коллегами. Это довольно явно поддерживается. Обычные пользователи Contributor не имеют этого права, но, согласно MSDN (см. Статью Разрешения Team Foundation Server в разделе Разрешения системы управления версиями), может быть предоставлено с помощью разрешения LabelOther:

Разрешения системы управления версиями относятся к файлам и папкам с исходным кодом. Вы можете установить эти разрешения, щелкнув правой кнопкой мыши папку или файл в Source Control Explorer, выбрав «Свойства» и на вкладке «Безопасность» выбрав пользователя или группу, для которых вы хотите изменить разрешения, а затем отредактировав разрешения, перечисленные в разделе «Разрешения». Вы можете установить эти разрешения с помощью утилиты командной строки tf для управления версиями.

...

Администрирование этикеток | tf: LabelOther | Пользователи, у которых есть это разрешение, могут редактировать или удалять ярлыки, созданные другим пользователем.

Итак, я назначил это право группе «Домен», в которую входят все разработчики, как было предложено выше. Я могу проверить, что он установлен, с помощью команды tf permission:

tf permission /group:"CORP\Web Team"

и результат ожидаемый (я также присвоил метку, просто для удовольствия)

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

Тем не менее, моему тестовому пользователю все еще не разрешено редактировать созданный мной ярлык.


tfs label
person Chris Wuestefeld    schedule 22.10.2008    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Могут ли полочные гарнитуры стать лучшим решением для вашей работы? IIRC существует довольно богатый API для работы с наборами полок, например для их фиксации как части процесса сборки (или другого).

Я обнаружил, что метки в TFS очень ограничены, когда я его использовал.

person cfeduke    schedule 22.10.2008
comment
То, что вы делаете, мне удалось сделать в продукте SourceGear Vault с продвижением этикеток, однако мне не удалось воспроизвести эту функцию в TFS, поэтому я обратился к полочным наборам. - person cfeduke; 22.10.2008
comment
Сейчас мы используем наборы полок, чтобы разработчики могли хранить свои изменения вне основного репозитория, пока он не будет готов. Однако, когда несколько разработчиков работают над взаимосвязанными вещами, им становится сложно делиться своими обновлениями таким образом. - person Chris Wuestefeld; 22.10.2008

arrow_upward
0
arrow_downward

Мне никогда не удавалось заставить это работать с лейблами. Вместо этого мы разработали совершенно другой процесс с использованием ветвления, который я настоятельно рекомендую всем, кто это читает.

Мы настраиваем схему ветвления так, чтобы была общая ветвь разработки; из этого у каждого разработчика есть своя собственная ветка, с которой они могут делать то, что они хотят, и есть производственная ветка.

  • Разработчики выполняют свою «грязную» работу в своей частной ветке, не опасаясь случайно выпустить что-то или даже помешать своим коллегам.
  • Когда у них есть что-то готовое для интеграции, они объединяют изменения в ветку разработки. Мы делаем там непрерывные сборки и тестируем результаты.
  • Когда интегрированная сборка полностью протестирована и готова к развертыванию, изменения переносятся в производственную ветвь. Это построено и развернуто.

Я сказал, что хочу

я пытаюсь использовать «плавающую» метку, чтобы разработчики могли указать, что их код готов стать частью сборки, пометив ее определенной меткой.

Схема, которую я изложил выше, полностью достигает этого и многого другого.

person Chris Wuestefeld    schedule 22.06.2010