решение варианта использования ртути

Question

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

Но полный ствол огромен, около 4-5 ГБ, и создание единого репо для всех модулей означает, что если мне когда-либо понадобится объединить репо, мне нужно переместить эти 4-5 гигабайт файла ... и я не могу взять резервная копия меньших модулей (так как у них нет папки .hg), которые находятся в одной базовой папке, где существует папка .hg, так как это не дало бы мне никакого способа комментирования из резервной копии модуля (папки). лучший способ справиться с ситуацией, когда в одном проекте много модулей и говорят ... все разработчики берут с собой свои отдельные модули (сохраняя размер передаваемых данных на минимальном уровне), кодируют, где хотят, и затем возвращают его обратно и объединить их филиал.

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

и более очевидным случаем было бы, если бы я преобразовал полную историю SVN в Mercurial .. Затем, если это преобразование будет сделано на транке, это сделало бы одно репо, но с огромным размером ... и каждый владелец модуля взял этот огромный комплект с он каждый раз был бы бессмысленным ..

Так какие-нибудь предложения ??

Спасибо.

Answer 1

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

Кроме того, если у вас есть очень большие файлы (> 10 МБ), накапливающие репо, вы можете использовать Расширение больших файлов , чтобы вывести их из-под прямого контроля, но при этом отслеживать их версию.

В целом, однако, я нахожу, что если я сделаю свои сценарии сборки достаточно полными, чтобы они загружали большие, не отредактированные вручную ресурсы вместо того, чтобы переводить их в систему контроля версий, репозитории, как правило, не увеличиваются до 4 или 5 ГБ. - это много KLoC. Может быть, эта миграция - хорошее время для использования инструмента загрузки зависимостей, например Ivy или любого другого, подходящего для вашей среды разработки.

Answer 2

На веб-сайтах мы помещаем все, кроме файлов MP3 и FLV, в Mercurial, и мы редко получаем более 300 МБ. Кроме того, диск дешевый. Если у вас есть проблемы с пропускной способностью между вами и сайтом клиента (или какие-то проблемы безопасности), вы можете просто клонировать все дерево на флэш-накопитель, перейти на сайт клиента и взломать, затем вернуться домой и изменения слияния.

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