Проверить Mercurial Checkins

Question

Есть ли способ проверить / подтвердить подлинность регистрации в Mercurial? Я хотел бы развернуть HG в нашей организации (более 60 разработчиков) и хотел бы, чтобы все проверки были от правильного пользователя и чтобы все они были в правильном формате.

В ходе испытаний мы обнаружили, что некоторые пользователи регистрировались под совершенно разными именами (скопировали чужой файл .hgrc), а другие - под разными версиями своего имени (имя, полное имя, адрес электронной почты и т. Д.), Используя разные клиенты.

Мы могли бы добавить хук для принудительного применения формата имени пользователя, но он все еще не гарантирует, что это правильный пользователь. У Mercurial есть что-то, чтобы справиться с этим, или я просто застрял в мышлении CVS / SVN?

Спасибо, Дэйв.

Answer 1

В основном вы находитесь в CVS / SVN - если ваши сотрудники нечестны, вы все равно облажались.:) Однако есть несколько способов, которыми другие люди справились с этим, используя различные методы:

• Mozilla и некоторые другие добавили видимый pushlog, который показывает, кто переместил каждый cset в каждый репо, поэтомувы получаете неявный шаг утверждения по пути
• , используя расширение gpg , вы можете убедиться, что csets подписаны, и написать быстрый changegroup хук, чтобы убедиться, что csets, входящие в защищенныйрепо были подписаны их автором
• . Вы можете написать ловушку, которая сравнивает часть имени электронной почты с переменной $REMOTE_USER (для http) или $USER (для ssh) и требует, чтобы она соответствовалаподталкивающий пользователь.

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

Опять же, на практике это простоне проблема, что все (включая меня) воображают, что это будет.В итоге получается, что на разных машинах существует много вариантов одного и того же имени, но любая команда, работающая с именами пользователей (churn и т. Д.), Получит карту псевдонимов, чтобы помочь вам сгруппировать их, если это имеет значение.

Answer 2

Во-первых, вы не можете проверить это во время фиксации, потому что у вас есть доступ к ревизии только после ее отправки в один из ваших центральных репозиториев.

Таким образом, вы можете убедиться, что тот, кто нажимает на cset, также является коммиттером (путем сопоставления аутентификации http или ssh). Это несколько ограничивает, потому что это может быть полезно, когда люди проталкивают изменения другим разработчикам.

Вы можете использовать расширение pgp (из hgext) для явной подписи наборов изменений после фиксации, но это своего рода перетаскивание, если вы хотите сделать это для каждого набора изменений.

commitsigs - еще одно расширение, которое требует другой тактики для подписи. Он встраивает подпись непосредственно в набор изменений, таким образом избегая беспорядка дополнительного набора изменений. Это добавляет накладные расходы около 2 КБ для каждого набора изменений.

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

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