Реальное использование Подвижных с Сервером Основы Команды?

Не уверен, что это то, чего вы еще не знаете, но я уже некоторое время использую mercurial локально, и пока я думаю, что преимущества перевешивают дополнительные накладные расходы на управление двумя системами контроля версий. Вот как я поступал:

1. Я сделал свою проверку TFS репозиторием HG, который считаю своим «главным». Я получаю обновления от TFS и фиксирую их в этом репозитории, поэтому он содержит самое текущее состояние проекта из TFS. Здесь важно то, что здесь нет никаких изменений, сделанных независимо от обновления TFS или слияния Hg (что является частью 2)

2. Каждый раз, когда мне нужно внести изменение, я клонирую свое «главное» репозиторий и выполняю свою работу. там. Я обнаружил, что клон для каждой функции или истории на самом деле довольно прост в управлении и кажется довольно чистым. После завершения функции я выполняю слияние Hg с «главным» репозиторием, к которому были применены все обновления TFS. Это позволяет мне использовать возможности слияния Mercurials, которые настолько превосходят TFS, что ставят под сомнение, как TFS вообще может претендовать на слияние кода. По завершении слияния я фиксирую его в Hg, а затем проверяю эти изменения в TFS. Лучшая часть этого заключается в том, что когда я проверяю TFS, мне не нужно ничего объединять. Очень очень хорошо.

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

1. Самая большая проблема заключается в том, что TFS плохо обнаруживает изменения. Существует плагин сделать доступным для записи , который можно использовать, чтобы сделать измененные файлы доступными для записи, когда они обновляются / объединяются Mercurial. Я нашел для этого два варианта.Вы можете либо заставить TFS перейти в автономный режим, после чего предполагается, что все, что доступно для записи, должно быть проверено, либо вы можете использовать инструмент сравнения в инструменте управления версиями и выбрать измененные файлы и индивидуально проверить их. Оба являются дерьмовыми IMO

2. Привязки системы управления версиями все еще существуют на уровне проекта, даже если вы исключите файлы системы управления версиями TFS из репозитория hg (что вам следует сделать). Это не совсем очевидно, пока вы не добавите файл в решение, после чего оно попытается добавить его в систему управления версиями. Вы можете «Отменить ожидающие изменения» и избавиться от добавления в систему контроля версий, но это действительно раздражает.

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

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

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

Обновление Я давно хотел обновить этот ответ, добавив дополнительную информацию, основанную на комментариях и моем опыте работы с большими репозиториями TFS.

Во-первых, как указывает @ Эрик Хекстер в комментариях, вы можете использовать расширение rebase , чтобы лучше интегрировать коммиты из ваших рабочих репозиториев в ваш основной репозиторий TFS. Хотя, в зависимости от того, как вы хотите, чтобы ваши коммиты отображались в TFS, вы можете использовать расширение сворачивания , чтобы свести ваши изменения в одну фиксацию (это может упростить откат в TFS). Также существует команда «онлайн» из TFS PowerTools , которая может упростить работу по информированию TFS о том, что изменилось (еще раз спасибо Эрику за упоминание этого в его сообщении в блоге )

. Когда я изначально писал это, я работал над проектом, который имел только одну ветвь TFS, которую использовали разработчики, и был довольно небольшим, поэтому клонирование репозиториев не представляло большого труда. Позже я обнаружил, что работаю над проектом, в котором репозиторий был размером около 1,5 ГБ после оформления заказа и намного больше после сборки, и довольно часто требовал переключения между ветками в TFS. Ясно, что этот подход не очень подходит для этой среды (особенно потому, что в какой-то момент было невозможно построить решения в произвольном каталоге.

Проблема размера лучше всего решается с помощью техники, аналогичной тематическим веткам gits, а не клонированием репозиториев в новые каталоги. Для этого есть несколько вариантов. Я думаю, что лучше всего использовать расширение закладок и создавать «закладки» тем, а не ветки тем. Вы также можете использовать именованные ветки, но у них есть небольшой недостаток в том, что они постоянны.и путешествуете с любыми клонами, которые вы можете использовать (если вы хотите поделиться своим изящным гибридом TFS-Hg с коллегой). Закладки являются локальными для вашего репо и фактически указывают на фиксацию и перемещаются с головой. Они реализованы так, что их можно использовать в любом месте, где Hg ожидает пересмотра (например, слияния, обновления и т. Д.). Вы можете использовать их для создания закладки TFS в качестве основной «ветки», которая получает обновления только из TFS и объединяет результаты работы по теме, каждая из которых будет иметь свои собственные закладки, и вы можете удалить их, как только вы вернетесь в TFS. Если вы предпочитаете использовать именованные ветки, вы можете применить точно такие же методы, что удобно.

Теперь проблема с несколькими ветвями сложнее, тем более что «ветки» TFS на самом деле являются копиями каждого файла из исходной ветки, а это означает, что каждый раз, когда вы извлекаете ветки из TFS, ваше репо будет становиться намного больше . Один из возможных способов справиться с этим - использовать комбинацию именованных ветвей Hg и закладок, чтобы у вас была ветка для каждой ветки TFS, а затем создавать закладки для своей работы из этих веток. Настоящая головная боль в этих сценариях на самом деле связана со всем этим с рабочими пространствами TFS. Вы можете удалить сопоставления в своих рабочих областях и уйти довольно далеко, но как только вы вернетесь к своему рабочему каталогу, вы должны быть осторожны, чтобы TFS не давила на файлы (на самом деле здесь вам пригодятся TF PowerTools). Попытка оставить рабочее пространство прикрепленным, пока вы переключаетесь между ветвями, становится ужасно быстро.Пара инструментов, которые неплохо иметь в своем наборе инструментов, - это расширение Hg purge и команда TF PowerTools "scorch". Оба эффективно удаляют файлы, которые не находятся в системе контроля версий (технически "обжиг" обеспечивает совпадение TFS и вашего локального рабочего каталога, чтобы он также мог обновлять файлы).

Однако для меня этот процесс стал довольно обременительным и подверженным ошибкам. Недавно я перешел на использование git с git-tfs , поскольку он управляет рабочими пространствами TFS за меня и снимает большую нагрузку, связанную с этой стороной. К сожалению, похоже, что нигде нет "hg-tfs", или я, вероятно, выбрал бы это.