Как лучше всего отслеживать личные файлы в публичном репозитории Mercurial?

«Если его нет в системе контроля версий, значит его не существует».

Этот вопрос был задан для Git здесь: Методы обработки частного и общедоступного репозитория ?. А что насчет Mercurial?

У меня есть несколько общедоступных репозиториев Bitbucket (с несколькими коммиттерами), где я бы хотел, чтобы источник был общедоступным, но которые загружают API, ключи SSH и другую конфиденциальную информацию из неотслеживаемых файлов. Однако это приводит к тому, что кто-то отправляет новый файл конфигурации по электронной почте, если мы добавляем новый ключ API Mailchimp, Hunch или Twilio. Есть ли способ как-то защитить эти файлы от публичного просмотра и при этом отслеживать их? Все синхронизируют свое репо через Bitbucket.


config private public mercurial
person Kevin Burke    schedule 03.05.2011    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Создайте filename.ext.sample файлы с шаблонами внутри (возможно, заполненными фиктивными данными), которые необходимо скопировать и заполнить фактическими данными в конкретном рабочем каталоге.

Я обычно так и делаю ;-)

person zerkms    schedule 03.05.2011

arrow_upward
3
arrow_downward

Есть два хороших способа справиться с этим (помимо решения zerkms, которое не предлагает простой синхронизации, которую вы хотите, но это то, что я бы сделал в любом случае):

  1. Используйте Mercurial Queues. Когда вы создаете ртутную очередь с hg qinit --create-repo, она создает систему наложения, которую можно qpush разместить поверх существующего репо. Таким образом, вы храните свои секреты в очередях и qpush их, когда они вам нужны, и qpop их, когда они вам не нужны. С --create-repo набор оверлеев (патчей) обрабатывается в собственном репозитории. Таким образом, знающие люди могут нажимать / извлекать секретное оверлейное репо, а люди, не имеющие к нему доступа, могут использовать базовое репо. Репозиторий патча может быть частным репо на битбакете или размещаться где-то еще.

    or

  2. Используйте вложенный репозиторий точно так, как описано в решении git.

person Ry4an Brase    schedule 04.05.2011

arrow_upward
0
arrow_downward

Решение Zerkms быстрое, простое и чистое, и, вероятно, ваш лучший выбор для предотвращения отслеживания / публикации защищенного контента; однако, как вы говорите: «Если этого нет в системе контроля версий, значит, его не существует». Я обнаружил, что гораздо чаще то, что я пытаюсь уберечь от контроля версий, - это не проблема безопасности, а просто параметр конфигурации. Я считаю, что эти следует отслеживать, и у моего нынешнего работодателя есть довольно умная установка для решения этой проблемы, которую я попытаюсь упростить / обобщить / резюмировать здесь.

REPOSITORY
  code/
    ...
  scripts/
    configparse.sh
    ...
  config/
    common.conf
    env/
      development.conf
      testing.conf
      production.conf
    users/
      dimo414.conf
      mycoworker.conf
      ...
    hosts/
      dimo414-laptop.conf
      dimo414-server.conf
      mycoworker-laptop.conf
      ...
    local.conf*
  makefile
  .conf*

* untracked file

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

Сценарий scripts/configparse.sh по очереди считывает все необходимые файлы конфигурации и строит .conf из всех найденных параметров.

  • config/common.conf является отправной точкой и содержит логические значения по умолчанию для каждой настройки. Многие, вероятно, будут перезаписаны, но здесь указано кое-что. Это ошибка, если параметр находится в другом файле, который изначально не задан в common.conf.
  • config/env/ управляет поведением в различных средах, например указывает на правильные серверы баз данных.
  • config/users/ ищет $USER.conf файл, полезный для настройки вещей, которые меня волнуют, например, увеличения уровня ведения журнала для аспектов, над которыми работает моя команда, или настройки поведения, которое я предпочитаю использовать на всех своих машинах.
  • config/hosts делает то же самое с машинами, ища $HOSTNAME.conf. Полезно для машинно-зависимых настроек, таких как пути к приложениям или каталоги данных.
  • config/local.conf - это неотслеживаемый файл, который позволяет вам устанавливать значения и / или контент, специфичные для оформления заказа, в системе контроля версий.

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

person dimo414    schedule 11.03.2013