Как крупные компании работают с Mercurial?
Я изучаю, как перенести наш контроль версий из SVN в Mercurial. Одна вещь, с которой я не уверен, что делать, это имена пользователей в коммитах. Из того, что я видел, нет способа заставить пользователя HG использовать конкретное имя пользователя, даже если оно указано в Mercurial.ini, пользователь может переопределить его в коммитах с флагом -u в hg commit.
Как компании справляются с этим? ничто не мешает разработчику А зафиксировать что-либо в своем репозитории как разработчика Б, а затем передать это кому-то другому.
Благодарю.
2 ответа
Я бы не сказал, что наша компания большая (4 разработчика), но это никогда не было для нас проблемой. Я не видел ни одного способа предотвратить такое поведение в своих поисках. Я предполагаю, что это сводится к проблеме доверия среди ваших разработчиков.
Независимо от этого, мы успешно перешли с SVN на Mercurial около двух лет назад, поэтому я могу ответить на другие ваши вопросы.
РЕДАКТИРОВАТЬ: идея:
Я не уверен, как вы планировали настроить свою топологию, но у нас есть сервер, который функционирует в качестве центрального репозитория для всех наших репозиториев. Можно проталкивать изменения между разработчиками (в обход центрального сервера), но мы никогда этого не делаем. Мы всегда фиксируем локально, а затем отправляем / извлекаем из / на центральный сервер. Кроме того, мы используем https и аутентификацию Windows для аутентификации на этом центральном сервере.
Если вы планируете иметь что-то подобное, вы можете создать ловушку на сервере (см. События хранилища) (возможно, precommit событие), которое будет проверять, что имя пользователя в каждом выдаваемом коммите совпадает с аутентифицированным пользователем с веб-сервера.
Не уверен, что это сработает, но звучит правдоподобно.
Еще одна попытка
ACL на основе пути в рабочем процессе псевдо-CVCS
Если вы будете использовать рабочий процесс "управляемой анархии" (p2p-коммуникации не контролируются, не ограничены и не являются доверенными, а единый авторитетный источник является распространенной целевой целью), вы можете использовать парадигму "Branch Per Developer". То есть - с расширением ACL на центральном репо применяются следующие ограничения:
- Никто не может нажать на ветку по умолчанию
- Каждый разработчик может выдвинуть только в свою личную ветку (под любым именем имя ничего не значит, auth-данные для отслеживания - это имя ветви)
- Только надежные слияния могут работать с repo-Central (объединить dev-ветви по умолчанию, NO rebase|NO rewrite в dev-branch)
- Каждый набор в ветви по умолчанию содержит часть аутентификации - ветку источника
Подписание веток
Если вы не можете доверять (и не должны доверять) имени пользователя в коммитах, вы можете доверять сильному шифрованию. У Mercurial есть по крайней мере два расширения, которые позволяют выполнять цифровую подпись коммитов, обеспечивая тем самым точную (так, см. Примечания ниже) информацию об авторстве с собственными преимуществами и недостатками в обоих случаях.
- Расширение Commitsigs Wiki и подписание Mercurial Changesets в Windows mini-HowTo достаточно полны, чтобы понять и продемонстрировать все аспекты запуска. Pro: никаких дополнительных коммитов для подписи, вы не можете (по замыслу) подписывать старые исторические коммиты. Против: не очень приятный вывод необходимых команд (см. Скриншоты в посте Дамиана для журнала и проверок), потому что это GnuPG (без PKI), теоретически возможно создать и использовать пару ключей для любого имени, адреса электронной почты и только "дополнительных" "сравнение покажет два разных ключа для одного пользователя
- Расширение GPG и Отчеты об одобрении из вики как быстрый старт. Pro:
может использовать pgp-ключи или openssl-certs (TBT!!!) (где openssl означает один корпоративный источник выданных сертификатов), более читаемый и информативный вывод команды sigcheck. Contra:
фиксация изменений в файле.hgsigs в корне рабочей копии, поэтому для этого требуются дополнительные наборы изменений. Это делает невозможным подписание всех наборов изменений. Файл.hgsigs также должен объединяться, как и любой другой файл, когда объединяются ветви.
и, наконец, файл может быть изменен вручную злоумышленником, как и любой другой файл в WC.
Редактирование и исправление ошибок Openssl можно использовать в Commitsigs, а не в расширении GPG.