TFS: создать новый проект из существующего в TFS

Каков наилучший способ создания совершенно нового проекта в TFS путем копирования существующего?

У меня есть проект ASP.NET, который будет иметь 50+ "выпусков" в год. Каждый выпуск представляет собой отдельный объект, который должен оставаться независимым от всех остальных. После создания я хочу убедиться, что любое изменение одного (исходный проект или копия) не влияет на другое.

Это только для контроля источника. Мне не нужно копировать какие-либо рабочие элементы.

В мире pre-TFS я бы сделал это, просто скопировав папку, содержащую все файлы проекта. Это имело у меня 90% пути к новому приложению, которое я мог бы адаптировать для нового выпуска. Очень редко мне нужно фактически добавлять функциональность в базовое приложение, и даже когда я это делаю, это никогда не затрагивает существующие приложения. Возможно ли это с помощью TFS, скопировав мои локальные папки, а затем добавив копию в TFS в качестве нового проекта?

Любые предложения? Один филиал в каждом выпуске выглядит как "стандартный" способ сделать это, но я быстро закончу десятками веток, которые действительно не связаны, и я предпочел бы сохранить каждый новый проект, поскольку он представляет собой отдельный проект, без каких-либо шансов изменения в одном влиянии на другое.

Спасибо!

Спасибо за ответы. Я думаю, вы все дали мне достаточно проницательности, чтобы начать. Ричард, спасибо за подробности. Я был немного обеспокоен тем, что было бы слишком легко случайно объединить ветки.

Ответ 1

Здесь есть два вопроса:

1) Лучше ли копировать/вставлять или вставлять?

Я бы рискнул сказать, что копирование/вставка никогда не подходит. Если вы не будете очень осторожны (как минимум, запустите "tfpt treeclean" непосредственно перед копированием), вероятно, вы закончите проверку некоторых неприемлемых файлов на новое место. Кроме того, вы будете использовать FAR больше дискового пространства на сервере, так как он должен хранить 50+ полных копий, а не просто diff.

Практически нет опасности, что ветки "случайно" начнут спускаться по линии. Объединение ветвей назад вместе включает в себя как минимум 3 преднамеренных шага: отложите слияние (сам по себе 4-страничный мастер), затем разрешите все конфликты, затем проверьте.

И вы, вероятно, не смутитесь о своем месте в дереве. TFS использует ветвь "path space". Это означает, что ветки отображаются пользователю как отдельные физические местоположения в исходном дереве, а не просто теги версии поверх одного и того же пути. Поскольку ветки выглядят как папки, вы можете выполнять на них все обычные операции с папками: Cloak (не загружать их в локальную рабочую область), Permission (в частности, удалять кого-либо. Разрешение на чтение гарантирует, что они даже не смогут его увидеть) Удалить или уничтожить (когда вы действительно сделали с ними).

2) Когда уместно создать новый проект команды?

Это более сложная тема в целом. Официальное руководство. Мое мнение.

Однако я бы сказал, что ваше дело легко: не делайте этого. У проектов команды много накладных расходов. Существует конечное число, которое вы можете создать на сервере... когда-либо. Не забывайте и о других формах накладных расходов, например, о времени, которое требуется администратору проекта для переноса по всем вашим настройкам, и времени, которое каждый разработчик в вашей команде тратит на повторное подключение своего Team Explorer.

Все для чего? В приведенных выше ссылках подробно описываются формы подструктуры, которые могут быть созданы внутри одного Team Project. Короче говоря, почти все возможно. Единственными областями, которые несколько не хватает, являются команды Queries и Build Definitions, которые ограничены одной папкой контейнера и несколькими настройками, такими как Exclusive Checkout, которые являются "ничего или ничего". Если у вас нет очень большой или очень разнообразной команды, выгоды от отдельных командных проектов за выпуск вряд ли перевесят недостатки.

Конечно, если "релиз" является основным событием, которое сигнализирует об изменении вашей практики SCM, это совсем другая история. Новый SCM = > новый шаблон процесса = > новый командный проект. Но я сомневаюсь, что вы делаете это 50 раз в год:)

Ответ 2

Я бы рекомендовал использовать ветвление. Создайте ветвь для каждой версии из основной ветки. Пока вы не объединяете ветки, они останутся независимыми. Изменения в главном ветки будут влиять только на выпуски, созданные после внесения этих изменений.

Вы можете скопировать файлы и создать новый проект, но вы можете столкнуться с несколькими проблемами:

Проекты "помнят", что они были в TFS, есть небольшая ручная работа по очистке специальных файлов и т.д.
TFS может замедляться, когда у вас много проектов, по сравнению с одним проектом с ветвями.

Ответ 3

Это может показаться очевидным, но вы должны создать новый проект для "нового проекта". Похоже, что вы говорите о разных версиях одного и того же проекта.

Если вы хотите сохранить отдельные кодовые базы для предыдущих выпусков, то, как сказали другие ответчики, разветвление кода - ваш лучший вариант. Это хорошо работает, когда вы хотите слить исправления ошибок с вашей последней версии на более старые версии.

Однако, если у вас действительно есть новые проекты, вы все равно используете ветвление таким же образом.