2017-01-27 3 views
1

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

В попытке придумать более безупречный способ решения этой проблемы я написал сценарий, который создаст символическую ссылку из репо в папку «скриптов» стороннего приложения и удалит другие символические ссылки, которые ранее была создана там. Это создаст двухэтапный процесс сценария update + run (хотя в будущем я могу перенести этот скрипт непосредственно в меркурий, чтобы сделать переключение для одной команды.)

Первый вопрос: имеет ли эта система символических ссылок смысл или есть лучший способ сделать это?

Второй вопрос: как я должен эффективно делиться этим файлом между репозиториями? Моя первая мысль - использовать subrepo, но это кажется излишним для простого скрипта, и его нужно будет вручную включить в каждое репо.

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

+0

Когда вы говорите ** субмодуль **, вы говорите об [подрепозитории] (https://www.mercurial-scm.org/wiki/Subrepository), правильно? –

+0

Да, моя ошибка. Я исхожу из фона Git и перепутаю два термина. Я обновлю его. – Fozefy

ответ

1

Есть несколько вариантов, но каждый из них имеет backdraws:

  • Вы можете сделать все проекты суб-Репо из одного, который содержит файлы сценариев и вспомогательные для создания проектов

  • Вы действительно можете сделать сценарий-репо суб-репо каждого проекта.

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

подход к югу репо имеет backdraws в том смысле, что вы начинаете использовать суб-репо, которые имеют неровные края в рабочем процессе. Поэтому я предлагаю вытащить и слить. Это дает вам небольшое дублирование (поскольку оно существует в каждом репо), увы, это один скрипт.

+0

и никогда не возвращайтесь к скрипту. Так что, возможно, крючок, чтобы охранять его – arhak

+0

Проблема в том, что в настоящее время у нас слишком много репозиториев для нашего собственного блага (мы работаем над их сокращением, но в настоящее время у нас есть несколько десятков). Этот сценарий является довольно простым на данный момент, но ожидание заключается в том, что он начнет обрабатывать больше случаев сборки для нас, и я хочу иметь возможность легко его обновлять, не требуя объединения в каждое репо. Это звучит так, как если бы первый или второй случай имел наибольший смысл, но я согласен, что он по-прежнему создает грубый рабочий процесс. – Fozefy

+0

Возможно использование гибридного подхода: сохранить (общий) скрипт в отдельном репо. И сохраняйте только в репозитории каждого проекта файл конфигурации, который читается этим скриптом, который сообщает ему, что нужно знать (тип проекта, возможно, какой-то путь или конфигурацию инструмента или что-то не). На моем сервере CI (jenkins) у меня есть сценарий сборки вместе с некоторыми инструментами в отдельном проекте. «Реальные» проекты имеют конфигурационный файл, специфичный для проекта, который сообщает скрипту сборки, как обрабатывать проект (существуют разные типы проектов). Таким образом, скрипт сборки получает путь и читает файл конфигурации из него, и из него следует все остальное. – planetmaker

Смежные вопросы