Я пытаюсь настроить новую структуру для нового репозитория TFS и пытаюсь сопоставить командные проекты с подпапками в структуре, подобной этой:
Root
- Trunc
- (TeamProject) proj1
- SubProj1
- SubProj2
- SubProj ...
- (TeamProject) proj2
- (TempProject) ...
- Global
- Выпуск
- proj1
- SubProj1 V3.5
- proj1 (филиал)
- SubProj2 (филиал)
- SubProj4 (филиал)
- Глобальный (филиал)
- SubProje1 V3.6
- proj1 (филиал)
- SubProj2 (филиал)
- SubProj4 (филиал)
- Глобальный (филиал)
- SubProje2 V2.1
- proj1 (филиал)
- SubProj1 (филиал)
- SubProj7 (филиал)
- Глобальный (филиал)
...
- proj2
...
- Третья сторона Libs
Речь идет о структуре, с которой мы до сих пор работали в различных scc-системах, и мы пытаемся объединить их все в новый репозиторий TFS.
На наш взгляд, эта структура имеет несколько преимуществ:
- Функциональность командного проекта TFS (Work Items, Builds) отдельно для каждой команды в компании, и списки, т. Е. Сборки, не слишком длинные для поиска, чтобы найти конкретный подпроект.
- Чтобы сопоставить хранилище с локальными жесткими дисками, нам нужно только синхронизировать путь «Trunc» в хранилище и путь «libs третьих лиц» и избегать загрузки всех ветвей последних 15 лет на каждый жесткий диск (гигабайты мусорной корзины). ). Основная подпапка Trunc содержит только активный исходный код, который каждый из нас использует каждый день.
- Чтобы исправить / перекомпилировать ветвь с хвостом хвоста, мы только проверяем определенную подпапку в выпусках (то есть / Release / Proj4 / SubProj2 V4.5 / *), размер которой составляет всего несколько мегабайт. После перестройки мы можем удалить сопоставление этой подпапки с жесткого диска ...
Я выглядел несколько иначе в сети, но кажется, что TFS слишком строг по своей структуре, и что только командные проекты могут быть расположены в корне хранилища. Это возможно? Разве нет способа управлять командными проектами в одном месте и обрабатывать ветки релизов в другом? А как насчет саморазвитых общих библиотек, которые используются в нескольких командных проектах?
В наших репозиториях (несколько) есть сотни проектов, сгруппированных по разным темам. Я хотел бы создавать командные проекты по темам и управлять реальными проектами в разных подпапках внутри командных проектов, используя отдельные файлы .sln. Но я бы очень хотел отделить ветки релизов от всех активных источников ...
Есть ли способ справиться с этим?
Спасибо за ваши ответы, я боялся услышать, что вы на самом деле ответили ...
У нас есть несколько командных проектов, которые используют одни и те же базовые библиотеки. В ветке релиза мы обычно также разветвляем эти базовые библиотеки, чтобы иметь стабильную позицию этих библиотек. В TFS, когда я использую разные командные проекты для приложений и отдельный командный проект для базовых библиотек, могу ли я затем создать ветку релиза моего App1, то есть «App1 V3.2», в которой путь моего приложения разветвляется, а также путь используемых библиотек? Или я должен также разветвлять базовый командный проект lib, когда делаю ветку релиза какого-либо приложения? Как я могу когда-либо найти правильный выпуск App1 для правильного выпуска моего, то есть base lib3 и base lib5?
Почему все из MS должно быть таким сложным? На первый взгляд это крутая система, но потом, когда вы пытаетесь ее использовать, оказывается, что вы должны полностью изменить свой способ работы в худшую сторону ...
Могу ли я использовать TFS ТОЛЬКО в качестве scc, например Perforce, Subversion или других?Есть ли способ избавиться от уровня команды team-project-root?Или есть способ определения проектов для подгрупп?
Хорошо, когда я решу сделать ОДИН проект большой команды, т.е. "Разработка", и иметь структуру подпапок, похожую на мой первый проект, как насчет элементов / сборок?Могу ли я поместить ie, например, в группы, представляющие фактическую аппликацию (я назвал ее подпроектом в своем проекте)?В противном случае у нас будет список сотен сборок в командном проекте «Разработка» и тысячи предметов, принадлежащих совершенно разным командам в компании ...