Не уверен, что это то, чего вы еще не знаете, но я уже некоторое время локально использую Mercurial, и до сих пор я думаю, что преимущества перевешивают дополнительные затраты на управление двумя системами контроля версий. Вот как я делаю вещи:
Я сделал свою проверку TFS репозиторием HG, который я считаю своим "хозяином". Я получаю обновления из TFS и фиксирую их в этом репозитории, поэтому в нем содержится самое актуальное состояние проекта из TFS. Здесь важно то, что в него не вносятся изменения независимо от обновления TFS или слияния Hg (которое является частью 2)
Каждый раз, когда мне нужно внести изменения, я клонирую свое «мастер» репо и выполняю там свою работу. Я обнаружил, что клон для каждой функции или истории на самом деле довольно прост в управлении и выглядит довольно чисто. После завершения функции я выполняю слияние Hg с «основным» репо, к которому применены все обновления TFS. Это позволяет мне использовать возможности слияния Mercurials, которые настолько превосходят TFS, что ставит под вопрос, как TFS может претендовать на слияние кода вообще. После завершения слияния я фиксирую это в Hg, а затем проверяю эти изменения в TFS. Самое приятное в этом то, что когда я делаю возврат в TFS, мне не нужно ничего объединять. Очень, очень мило.
Теперь вот проблемы, которые я обнаружил при таком подходе:
Самым большим является тот факт, что TFS паршивая при поиске изменений. Существует плагин make write , который вы можете использовать, чтобы сделать измененные файлы доступными для записи, когда они обновляются / объединяются Mercurial. Есть два варианта, которые я нашел для этого. Вы можете либо заставить TFS перейти в автономный режим, после чего он будет предполагать, что нужно записать что-либо доступное для записи, либо вы можете использовать инструмент сравнения в инструменте управления версиями, выбрать измененные файлы и проверить их по отдельности. Оба дерьмовые ИМО
Привязки управления исходным кодом все еще присутствуют на уровне проекта, даже если вы исключили файлы управления исходным кодом TFS из своего репозитория hg (что вы должны сделать). Это не очевидно до тех пор, пока вы не добавите файл в решение, после чего он попытается добавить его в систему контроля версий. Вы можете «Отменить ожидающие изменения» и избавиться от добавления управления исходным кодом, но это действительно раздражает.
Хорошей новостью является то, что я использовал этот подход для прохождения довольно масштабного слияния, которое, я думаю, заставило бы меня обратиться к какой-либо форме тяжелых наркотиков, если бы я был вынужден использовать для этого инструменты TFS.
Я еще не применял это для обновления веток в TFS, но я предполагаю, что это будет намного лучше, чем опции, которые вам даются для слияния в TFS. В связи с этим, поскольку вы можете одновременно проверять фрагменты рабочего функционала, использование слияния TFS будет менее проблематичным только потому, что все необходимые для функции изменения будут объединены в одном месте.
Одна вещь, которую я не пытался решить, - это делиться этим со всей командой. Частично причина в том, что это не обязательно должно быть делом всей команды. Я работаю удаленно, поэтому наличие локального репозитория очень важно и экономит много времени. Другие члены моей команды разработчиков могут получить или не получить такую же выгоду от этого подхода, но я нахожу это довольно круто, что я могу , не влияя на то, как они работают.
Обновление
Я давно хотел обновить этот ответ, добавив дополнительную информацию, основанную на комментариях и некотором опыте работы с большими репозиториями TFS.
Сначала как @ Эрик Хекстер указывает в комментариях, вы можете использовать расширение rebase , чтобы лучше интегрировать коммиты из ваших рабочих репозиториев в ваш основной репозиторий TFS. Однако, в зависимости от того, как вы хотите, чтобы ваши коммиты отображались в TFS, вы можете использовать расширение свертывания , чтобы объединить ваши изменения в один коммит (это может упростить откат в TFS). Существует также команда «online» из TFS PowerTools , которая может упростить задачу TFS, чтобы узнать, что изменилось (еще раз спасибо Эрику за упоминание об этом в своем сообщении в блоге )
Теперь, когда я изначально писал это, я работал над проектом, который имел только одну ветку TFS, которую использовали разработчики, и был довольно маленьким, поэтому клонирование репозиториев не было большой проблемой. Позже я обнаружил, что работаю над проектом, репо которого составляет около 1,5 ГБ после извлечения и намного больше после сборки, и довольно часто включающим переключение между ветвями в TFS. Очевидно, что этот подход не очень подходит для этой среды (особенно потому, что в какой-то момент было невозможно построить решения в произвольном каталоге.
Проблему размера лучше всего решить, используя технику, похожую на ветки темы gits, а не клонируя репозитории в новые каталоги. Есть несколько вариантов для этого. Я думаю, что на самом деле лучше всего использовать расширение для закладок и создавать «закладки» темы, а не ветки тем. Вы также можете использовать именованные ветки, но у них есть небольшой недостаток: они постоянны и путешествуют с любыми клонами, которые вы можете делать (если вы хотите поделиться своим отличным гибридом TFS-Hg с коллегой). Закладки являются локальными для вашего репо и эффективно указывают на коммит и путешествие с головой. Они реализованы так, что их можно использовать в любом месте, где Hg ожидает пересмотра (слияния, обновления и т. Д.). Вы можете использовать их для создания закладки TFS в качестве основной «ветви», которая получает обновления только от TFS и объединяет ее с работой темы, каждая из которых имеет свои собственные закладки, и вы можете удалить ее после того, как вы вернетесь в TFS. Если вы предпочитаете использовать именованные ветви, тогда вы можете применять точно такие же методы, что удобно.
Теперь, проблема с несколькими ветвями сложнее, особенно потому, что «ветви» TFS на самом деле являются копиями каждого файла из исходной ветви, что означает, что каждый раз, когда вы извлекаете ветви из TFS, ваше хранилище будет становиться намного больше , Один из возможных способов справиться с этим - использовать комбинацию именованных веток Hg и закладок, чтобы у вас была ветвь для каждой ветки TFS, а затем создавать закладки для вашей работы из этих ветвей. Настоящая головная боль в этих сценариях на самом деле связана с рабочими пространствами TFS через все это. Вы можете удалить сопоставления в своих рабочих пространствах и получить довольно далеко, но как только вы вернетесь обратно к своему рабочему каталогу, вы должны быть осторожны с топлением файлов TFS (это действительно, где TF PowerTools пригодится). Попытка оставить рабочее пространство подключенным, в то время как переключение вокруг вас становится ужасно быстрым. Пару инструментов, которые приятно иметь в своем наборе инструментов, это расширение очистки Hg и команда TF PowerTools "scorch". И те, и другие эффективно удаляют файлы, которые не находятся под контролем версий (технически «палящий» обеспечивает соответствие TFS и вашего локального рабочего каталога, поэтому он также может обновлять файлы).
Однако для меня этот процесс стал довольно обременительным и подверженным ошибкам. Недавно я перешел на использование git с git-tfs , поскольку он управляет рабочими пространствами TFS для меня и снимает большую часть нагрузки, связанной с этой стороной. К сожалению, нигде не существует "hg-tfs", или я, вероятно, выбрал бы это.