Здравствуйте, WSA, Вы писали:

WSA>Есть Mercurial репозиторий с программным решением, который используется внутри компании ограниченным кругом разработчиков.
WSA>В данном репозитории есть конфигурационные файлы с подключением к БД.

Надежнее всего не хранить конфиги с реальными параметрами БД, а хранить их где-то отдельно (на стендах или в другом закрытом репозитории, если нужна историчность).
Если можно обойтись локальной базой, можно для разработки хранить в репозитории параметры соединения с такой локальной БД, унифицированной по всем разработчикам (типа server=localhost;db=project_dev;user=localdev;password=localdev). На тест- и препрод- стендах — свои конфиги со своими базами.

Если нужна какая-то централизованная, но разная для разных разработчиков или реальная, которую нельзя светить, — то конфиг с соединением с БД не хранится, хранится его пример, а разработчик уже себе его настраивает под себя. Такой файл должен быть игнорируемым в hg, чтобы случайно не был сложен с реальными параметрами, что может быть не очень удобно, если в конфиге и база и другие параметры, которые меняются. В .net может помочь встроенная поддержка иерархии конфигов, т.е.
* appsettings.json — базовые настройки, тут реальной строки соединения нет.
* appsettings.dev.json — игнорируемый в hg, персональные настройки разработчика в т.ч. важные строки соединения и т.д., переписывающие базовые настройки.

WSA>Хотим скрыть данные о подключении к основной БД, но они есть в истории.
Тут боюсь только поменять учетку в БД. Отдельные коммиты можно удалить из истории, но коммиты, а не их части, да и для старой истории, которая уже расползалась по разным местам это та еще головная боль, не советую.

Здравствуйте, WSA, Вы писали:

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

WSA>Дело в том, что по факту пароли уже там есть. Нужно найти решение исходя их реальной ситуации, по факту. А вот как их хранить дальше это уже вторая проблема. Будем хранить однозначно отдельно. А сейчас нужно дать код программисту, сохранить версионность кода и не сломать основную БД.

1. Поменять пароли в БД
2. Убрать пароли из репозитория с сырцами
3. Дать доступ к сырцам для девелоперов

Вроде все просто?

Здравствуйте,

Есть Mercurial репозиторий с программным решением, который используется внутри компании ограниченным кругом разработчиков.
В данном репозитории есть конфигурационные файлы с подключением к БД.
В данный момент планируем привлеч к разработке удалённого сотрудника. Но есть необходимость ограничить его доступ к основной БД.
Решили запустить новый инстанс с БД, куда будут реплицироваться данные с основной БД.
К данной БД дать доступ удалённому разработчику для его экспериментов.

Хотим скрыть данные о подключении к основной БД, но они есть в истории.
Ищу решение этой проблемы. Как вариант теоретически это может быть ещё одна версия репозитория, с которой можно будет каким-то образом мержить основную версию.

Прошу посоветовать решение для этой проблемы.

Здравствуйте, fmiracle, Вы писали:

Спасибо за подрообный ответ.

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

А можно ли сделать эквивалентную копию репозитария, как бы с нуля, скопировав туда содержимое последней версии репозитория и мержить этот новый репозиторий с основным....
Ещё изучаю вариант ограничения пользователя репозитория, но кажется allow_read permission действует на весь репозиторий, былобы неплохо ограничить чтение default-ветки, а удалённому сотруднику открыть параллельную ветку и разрешить работать только с ней. Мержить с default-веткой без привлечения удалённого разработчика.

Здравствуйте, WSA, Вы писали:

WSA>Прошу посоветовать решение для этой проблемы.

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

Здравствуйте, GarryIV, Вы писали:


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

Дело в том, что по факту пароли уже там есть. Нужно найти решение исходя их реальной ситуации, по факту. А вот как их хранить дальше это уже вторая проблема. Будем хранить однозначно отдельно. А сейчас нужно дать код программисту, сохранить версионность кода и не сломать основную БД.

Здравствуйте, WSA, Вы писали:

WSA>А можно ли сделать эквивалентную копию репозитария, как бы с нуля, скопировав туда содержимое последней версии репозитория и мержить этот новый репозиторий с основным....
WSA>Ещё изучаю вариант ограничения пользователя репозитория, но кажется allow_read permission действует на весь репозиторий, былобы неплохо ограничить чтение default-ветки, а удалённому сотруднику открыть параллельную ветку и разрешить работать только с ней. Мержить с default-веткой без привлечения удалённого разработчика.

Сомневаюсь что выйдет что-то путное.
К тому же в какой-то момент захочется ведь смержить в обе стороны — из вашего основного в тот репозиторий для внешнего разработчика, чтобы у него были и ваши изменения, и тут можно опять упустить попадание туда паролей.
Так что проще и спокойнее сменить пароль все же.