Папки TFS - заставить их работать как Subversion «Магистральные / Теги / Ветви»

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

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

То, что вы считаете «тегами, ветвями и магистралями». все представлены папками в TFS. «Ствол» - это папка, созданная простым добавлением, а не ветвью другой папки. «Ветвь» - это папка, полученная из (и отныне связанная) с другой папкой в ​​другом месте системы с помощью операций Branch & Merge. TFS как таковой не имеет «тегов»; ближайшим аналогом является создание ветки на основе исторической версии (через номер набора изменений или метку). И снова это становится еще одной папкой.

Когда дело доходит до управления вашим локальным рабочим пространством, концепция «все в папке» хорошая новость. Если вы хотите создать произвольно сложные представления для тегов / ветвей / магистралей, в мире TFS эта задача сводится к очень простой проблеме сопоставления локальных путей <-> серверных путей.

Конечно, это не значит, что вы должны . Дисковое пространство намного дешевле пропускной способности сети или циклов ЦП сервера. Что еще более важно: чем сложнее ваши сопоставления, тем выше вероятность, что вы случайно зафиксируете неправильный файл в неправильном месте. Моя обычная рекомендация:

1. Создайте по одной рабочей области для каждой ветви / тега, над которой вы активно работаете.
2. В каждой рабочей области создайте только одно рекурсивное сопоставление с корнем ветви.
   • Если это невозможно из-за размера ветвей, избегайте плащей. Это не лучшее решение, потому что они не будут синхронизироваться с добавлением / переименованием папок, сделанными другими людьми. Лучше использовать одноуровневое сопоставление с корнем ветки + дополнительные рекурсивные сопоставления с нужными вам папками.
   • Если это невозможно, потому что у вас есть зависимости времени сборки, не содержащиеся в ветке, позор вам :) Добавьте наименьшее количество дополнительных сопоставлений с общими библиотеками, насколько это возможно.
3. Убедитесь, что относительные пути одинаковы в каждой ветви. (И если они меняются, изменения в структуре распространяются синхронно с изменениями в ваших make-файлах.)
4. Создайте одно дополнительное рабочее пространство для того, что я назову «задачами обслуживания». §

Эта стратегия обеспечивает:

• Нулевые накладные расходы на ресурсы. При переключении контекста повторная загрузка не требуется.
• Низкие умственные издержки. Чтобы начать работу над другой веткой, просто откройте другую копию решения с диска. Или измените раскрывающееся меню «Рабочая область» в Source Control Explorer.
• Низкая вероятность ошибок. Поскольку ветки ограничены своей собственной рабочей областью, нажатие кнопки «Проверить все» никогда не приведет к фиксации изменений, ожидающих выполнения в другой ветке ... или, что еще хуже, вы не можете случайно внести изменения в ветку «релиз», которые должны были идти вразрез с «нестабильной» "версия.

Я хочу, чтобы на моем жестком диске была корневая папка" Проект / Веб-сайт "и чтобы она указывала (отображалась) на теги, ветки или ствол, в зависимости от того, что я я делаю это, без необходимости возиться с исправлением ссылок на проекты Visual Studio.

Это тоже возможно. Как уже упоминалось, вы просто меняете дисковое пространство на пропускную способность / процессор. Ничего страшного, если ваша инфраструктура поддерживает это. Лично я считаю это слишком ограничивающим с точки зрения параллельной разработки, плюс более высокая вероятность ошибок, но вполне естественно, что человек, выросший на SVN, может чувствовать иначе.

Вот шаги:

1. Создайте одно рабочее пространство. Сопоставьте его с веткой / тегом / стволом, над которым вы собираетесь работать дальше.
2. Следуйте всем остальным рекомендациям, приведенным выше.
3. Когда придет время изменить ветку / тег / магистраль, снова откройте диалоговое окно «Рабочая область» и укажите в той же локальной папке новый путь к серверу.
4. Получить последнюю версию. Вполне естественно, что человек, выросший на SVN, может чувствовать иначе.

   Вот шаги:

   1. Создайте одно рабочее пространство. Сопоставьте его с веткой / тегом / стволом, над которым вы собираетесь работать дальше.
   2. Следуйте всем остальным рекомендациям, приведенным выше.
   3. Когда пришло время изменить ветку / тег / магистраль, снова откройте диалоговое окно «Рабочая область» и укажите в той же локальной папке новый путь к серверу.
   4. Получить последнюю версию. Вполне естественно, что человек, выросший на SVN, может чувствовать иначе.

      Вот шаги:

      1. Создайте одно рабочее пространство. Сопоставьте его с веткой / тегом / стволом, над которым вы собираетесь работать дальше.
      2. Следуйте всем остальным рекомендациям, приведенным выше.
      3. Когда пришло время изменить ветку / тег / магистраль, снова откройте диалоговое окно «Рабочая область» и укажите в той же локальной папке новый путь к серверу.
      4. Получить последнюю версию.
         • Начиная с TFS 2008, клиент будет автоматически предлагать вам запустить Get каждый раз, когда вы вносите подобное изменение.
         • Начиная с TFS 2008 SP1, есть еще лучший способ. В приглашении нажмите «нет», затем запустите tf get / remap . Это загрузит только различия между двумя ветками. Это может привести к огромной экономии ресурсов пропускной способности / ЦП в зависимости от размера папки и степени их взаимосвязи. (На самом деле может потребоваться больше ЦП сервера для папок, которые очень маленькие, очень удаленно связаны или [конечно] вообще не связаны; используйте здравый смысл. Однако всегда требуется строго меньшая пропускная способность.)

      ---

      ‡ В TFS, когда вы создаете ветку, она представляется пользователю как совершенно новая иерархия папок. Иными словами: когда вы смотрите на репозиторий априори , нет четкого способа отличить «настоящие» файлы / папки из веток. И, честно говоря, здесь нет большой разницы. «Ветвь» - это просто еще один элемент, с которым связано> = 1 часть метаданных истории слияния. Множество команд TFS зависят от указанных метаданных, и вы, конечно, можете запросить их напрямую, но они не будут отображаться в простом tf dir . Между тем, поскольку каждая ветвь занимает уникальную позицию в пространстве путей , это означает, что однозначно указать разветвленную версию спецификации не более или менее сложно. $ / path; changeset достаточно, как и любой другой элемент.

      CVS использует противоположный подход. При ветвлении путь не меняется. Вместо этого вы разделили версий по другому измерению. Это упрощает визуализацию простых случаев: есть только одно дерево. Конечно, вы только переместили сложность в другое место. Когда вы хотите однозначно указать версию элемента, знать путь и номер версии уже недостаточно; вам тоже нужно знать ветку. А что, если вы переименуете файл в одной ветке, а в другой - нет? В TFS никого не волнует, пока не придет время объединить ветки; в CVS просто просмотр репозитория вызывает проблему. Я уверен, что вы можете подумать и о других тонкостях - я недостаточно знаком с этим, чтобы знать, как он обрабатывает каждый крайний случай.

      Большинство систем SCC находятся где-то между этими крайностями. Назовем TFS 2005/2008 крайним «левым», а CVS - противоположным «правым».

      Subversion находится в основном поверх TFS на «левом» полюсе. Хотя реализации сильно различаются, пользовательский взгляд на ветвление почти идентичен теперь, когда наконец реализовано отслеживание слияния. (Можно утверждать, что до версии 1.5 он был даже немного левее, чем TFS. Ветви были просто копиями с низкоуровневой оптимизацией; у пользователя не было возможности запрашивать реляционные метаданные. SourceSafe попадает в ту же категорию, если не осталось даже дальше из-за отсутствия общесистемных номеров версий.) Пользователи, пришедшие из мира SVN, не должны испытывать затруднений, когда они поймут модель рабочего пространства клиент / сервер и переделают свою терминологию. (SVN имеет много CVS-багажа в своих терминах, например, в слове «тег»; справедливости ради TFS унаследовал некоторую словесную неразбериху от VSS, например, повсеместное использование «checkin / checkout», несмотря на то, что по умолчанию это редактирование-слияние-фиксация. )

      Perforce находится на одну ступеньку правее TFS. Их основная модель идентична. У них есть дополнительная концепция спецификаций ветвей , которые соответствуют некоторым распространенным пользовательским сценариям - например, быстрое знание того, «какие папки представляют ветви», ярлыки для указания разветвленных спецификаций версий без необходимости полного пути - но это просто синтаксис сахар.

      TFS 2010 находится еще на пару ступенек вправо. Как и Perforce, они создали хранилище «объектов ветвей», которые существуют независимо от дерева репозитория (но сопоставляются). Каждая ветвь также знает свои отношения (например, родительский, дочерний, безосновный) в пределах определенной пользователем иерархии ветвей .

      Я бы разместил ClearCase примерно на 2/3 пути до право. Сложные сценарии ветвления в основном происходят в пространстве версий с точки зрения сервера. Однако у них есть чрезвычайно мощная система "просмотров", наложенная сверху. В результате структура, которую фактически видит пользователь, может быть изменена, чтобы напоминать пространство путей или какой-то гибрид. Аналогичный уровень настраиваемости применяется к сопоставлениям их локальных рабочих пространств.

      Большинство других «корпоративных» SCM расположены примерно на 3/4 вправо. (например, AccuRev, MKS, StarTeam) Пользователи обычно могут просматривать репозиторий + дерево ветвей различными мощными способами, но не могут настраивать саму систему так гибко, как CC. Вероятно, это хорошо :)

      CVS находится в крайнем правом углу, как описано ранее. То же самое, что и его предки RCS и SCCS.

      Классификация распределенных систем, таких как Monotone, BitKeeper, изолирован от моего повседневного развития. Наличие собственного рабочего пространства также означает, что я могу отображать огромные части репозитория одним махом, не загружая их. (Напротив, в ваших рабочих областях «разработки» лучше всего запускать Get без каких-либо ограничительных областей пути.) И, как я уже упоминал несколько раз, теперь сохраняя широкое и простое отображение локального сервера <-> пути остаются постоянными, ссылки не прерываются, файлы не фиксируются случайно или не попадают в неправильное место; все в целом счастливее.

      YMMV.

      Лучшая практика для запуска Get без каких-либо ограничительных областей пути.) И, как я уже несколько раз упоминал, сохранение широкого и простого отображения локального сервера <-> означает, что относительные пути остаются постоянными, ссылки не прерываются, файлы не не попасть случайно или не в то место; все в целом счастливее.

      YMMV.

      Лучшая практика для запуска Get без каких-либо ограничительных областей пути.) И, как я уже несколько раз упоминал, сохранение широкого и простого отображения локального сервера <-> означает, что относительные пути остаются постоянными, ссылки не прерываются, файлы не не попасть случайно или не в то место; все в целом счастливее.

      YMMV.