Ответ 1
Первое, что нужно понять, это то, что модель TFS дерева версий отличается от того, к чему вы можете привыкнуть. Он находится на крайнем конце спектра. ‡
Я использовал Subversion уже пару лет и люблю, как это работает. Я всегда настраивал три папки под каждым проектом, Trunk, теги и ветки.
То, что вы считаете "тегами, ветвями и соединительными линиями", представлено всеми папками в TFS. "Строка" - это папка, созданная простым добавлением, а не как ветка другой папки. "Ветвь" - это папка, полученная из (и в дальнейшем связанная) с другой папкой в другом месте системы через операции "Ветка" и "Слияние". TFS не имеет "тегов" как таковых; ближайший аналог - создать ветвь, основанную на исторической версии (через номер набора изменений или метку). Еще раз, это станет еще одной папкой.
Когда дело доходит до управления вашей локальной рабочей областью, концепция, что "все папки" - хорошая новость. Если вы хотите создать произвольно сложные представления по тегам/ветвям/соединительным линиям, в мире TFS эта задача сводится к очень простой проблеме сопоставления путей локальных путей ↔ server.
Конечно, это не значит, что вам нужно. Дисковое пространство намного дешевле, чем пропускная способность сети или процессорные циклы серверов. Что еще более важно: чем сложнее ваши сопоставления, тем более вероятно, что вы случайно ошиблись в неверном файле. Моя обычная рекомендация:
- Создайте одно рабочее пространство для каждой ветки/тега, с которой вы активно работаете.
- В каждой рабочей области создайте только одно рекурсивное отображение в корень ветки.
- Если это невозможно из-за размера ветвей, избегайте плащей. Они не являются хорошим решением, потому что они не будут синхронизироваться с добавлением/переименованием папки, сделанными другими людьми. Лучше использовать одноуровневое сопоставление с корнем ветки + дополнительные рекурсивные сопоставления в нужные вам папки.
- Если это невозможно, потому что у вас есть зависимости времени сборки, не содержащиеся в ветке, позор вам:) Добавьте наименьшее количество дополнительных сопоставлений в общие библиотеки, насколько это возможно.
- Убедитесь, что относительные пути одинаковы в каждой ветки. (И если они меняются, изменения в структуре распространяются в lockstep с изменениями в ваши make файлы.)
- Создайте еще одно рабочее пространство для задач, которые я буду называть "обслуживание".§
Эта стратегия обеспечивает:
- Накладные расходы нулевого ресурса. При переключении контекста не требуется перезагрузка.
- Низкие умственные накладные расходы. Чтобы начать работу с другой ветвью, просто откройте другую копию решения с диска. Или измените раскрывающееся меню рабочей области в проводнике исходного кода.
- Низкий шанс нанести ущерб. Поскольку ветки ограничены собственным рабочим пространством, нажатие кнопки "Проверить все" никогда не приведет к изменениям, которые ожидали в другой ветке... или, что еще хуже, вы не можете случайно внести изменения в ветвь "выпуска", которые должны были идти против "нестабильной" ".
То, что я хочу сделать, это иметь корневую папку "Проект/Веб-сайт" на моем жестком диске и иметь возможность указывать (сопоставлять) теги, ветки или соединительные линии в зависимости от того, что я делаю, без необходимости прикручивать с помощью ссылок на проекты Visual Studio.
Это тоже возможно. Как уже упоминалось, вы просто торгуете дисковым пространством для пропускной способности/ЦП. Неважно, поддерживает ли ваша инфраструктура. Я лично считаю это слишком ограниченным с точки зрения параллельного развития, плюс более высокий шанс нанести ущерб - но только естественный человек, поднятый на SVN, может чувствовать себя по-другому.
Вот шаги:
- Создайте одно рабочее пространство. Сопоставьте его с веткой/тегом/туловищем, над которым вы собираетесь работать дальше.
- Следуйте всем приведенным выше рекомендациям.
- Когда придет время изменить ветку/тег/соединительную линию, закройте диалоговое окно "Рабочая область" и укажите ту же локальную папку на новый путь к серверу.
- Получить последний.
- Начиная с TFS 2008, клиент автоматически предложит вам запустить Get в любое время, когда вы сделаете такое изменение.
- Начиная с TFS 2008 SP1, существует еще лучший способ. Нажмите "нет" в приглашении, затем запустите tf get/remap, Это будет загружать только разницы между двумя ветвями. Это может быть огромная экономия пропускной способности/ЦП в зависимости от размера папки и того, насколько тесно они связаны. (Возможно, на самом деле требуется больше серверного процессора в папках, которые очень малы, очень отдаленно связаны или, конечно, не связаны вообще, пользуйтесь здравым смыслом. Однако всегда нужно брать меньше полосы пропускания.)
‡ В TFS при создании ветки она появляется в качестве новой иерархии папок. Иными словами: когда вы смотрите на репозиторий априори, нет четкого способа отличить "реальные" файлы/папки от веток. И, откровенно говоря, нет большой разницы. "Ветвь" - это еще один элемент, который имеет >= 1 часть метаданных истории слияния, связанных с ним. Множество команд TFS зависит от указанных метаданных, и вы можете запросить их напрямую, но это не будет отображаться в простой tf dir. Между тем, поскольку каждая ветвь занимает уникальное положение в пространстве пути, это означает, что она не более или менее сложна, чтобы однозначно указать разветвленную версию. $/путь, changeet достаточно, как и любой другой элемент.
CVS использует противоположный подход. Когда вы введете ветку, путь не изменится. Вместо этого вы делаете раздвоение версий по другому измерению. Это делает простые случаи очень легкими для визуализации: есть только одно дерево. Конечно, вы только переместили сложность в другом месте. Если вы хотите однозначно указать версию элемента, знать путь и номер ревизии уже недостаточно; вам также нужно знать ветку. А что, если вы переименуете файл в одну ветку, а не в другую? В TFS никто бы не заботился, пока не пришло время объединить ветки; в CVS просто просмотр репозитория вызывает проблему. Я уверен, что вы можете думать о других тонкостях - я недостаточно знаком с ним, чтобы знать, как он обрабатывает каждый случай с краем.
Большинство систем SCC находятся где-то между этими крайностями. Позвольте TFS 2005/2008 назвать "левые" и CVS противоположными "правыми".
Subversion сидит в основном на вершине TFS на "левом" полюсе. Хотя реализации сильно различаются, пользовательский вид ветвления почти идентичен теперь, когда окончательно реализовано отслеживание слияния. (Можно утверждать, что до v1.5 он был еще немного дальше, чем TFS. Филиалы были просто копиями с оптимизацией на низком уровне, у пользователя не было возможности запросить реляционные метаданные. SourceSafe относится к этой же категории, если они еще не оставлены из-за отсутствия системных номеров версий.) Пользователи, выходящие из мира SVN, не должны испытывать трудностей, когда они понимают модель рабочего пространства клиент/сервер и переписывают свою терминологию. (SVN имеет много багаж CVS в своих терминах, например, слово "тег"; в справедливости TFS наследует некоторую вербальную crud из VSS, например, повсеместное использование "checkin/checkout", несмотря на то, что по умолчанию выполняется компиляция с фиксацией прав).
Perforce находится на одной отметке справа от TFS. Их базовая модель идентична. Они имеют дополнительную концепцию отраслевых спецификаций, которые соответствуют некоторым обычным сценариям пользователя - например, быстро зная, "какие папки представляют ветки", ярлыки для указания разветвленных версий версий без необходимости полного пути, но это просто синтаксический сахар.
TFS 2010 - еще одна пара вырезов справа. Как и Perforce, они создали хранилище "объектов ветвления", которые существуют независимо от (но вернут карту) к дереву репозитория. Каждая ветвь также знает свои отношения (например, родительский, дочерний, необоснованный) в пределах иерархии веток, определенных пользователем.
Я бы поставил ClearCase примерно на 2/3 пути вправо. Сложные сценарии ветвления принципиально происходят в пространстве версий с серверной точки зрения. Однако у них есть чрезвычайно мощная система "взглядов", расположенных сверху. В результате структура, которую фактически видит пользователь, может управляться, чтобы напоминать пространство пути или какой-то гибрид. Подобный уровень настраиваемости применим к их локальным сопоставлениям рабочего пространства.
Большинство других "корпоративных" SCM составляют около 3/4 пути вправо. (например, AccuRev, MKS, StarTeam) Пользователи обычно могут просматривать дерево репозитория + дерево различными способами, но не могут настроить систему как гибко, как CC. Это, наверное, хорошо:)
CVS находится в крайнем правом углу, как описано выше. Тоже его предки RCS и SCCS.
Классификация распределенных систем, таких как Monotone, BitKeeper и их производных, выходит за рамки этого ответа:)
§ Пара новых операций в TFS может выполняться без рабочего пространства:
- Создание ветки (tf branch/checkin - требуется SP1 2008)
- Уничтожение предметов (требуется 2008)
Некоторые другие требуют сопоставления в рабочее пространство, но не требуют загрузки каких-либо файлов:
- Удаление элементов
- Блокировка элементов
- Создание ветки по старому пути (tf branch/noget - доступно с ранних бета-версий 2005 года).
Еще несколько требуют частичных отображений и/или частичной загрузки:
- Слияние требует только сопоставления и загрузки целевого пути.
- Переименование требует отображения обоих путей и загрузки цели.
- Undelete/newname работает как Rename.
Я предпочитаю делать подобные операции в своем собственном рабочем пространстве "обслуживания", изолированном от моей повседневной разработки. Наличие собственного рабочего пространства также означает, что я могу набросать огромные части репозитория одним махом, не загружая их. (Напротив, в ваших рабочих пространствах "разработки" лучше всего использовать Get без каких-либо ограничительных путей пути.) И как я уже упоминал несколько раз, теперь локальное ↔ серверное отображение широко и просто означает относительные пути остаются постоянными, ссылки не прерываются, файлы не попадают случайно или не совершаются в неправильном месте; все в целом счастливее.
YMMV.