Как заблокировать ствол SVN, за исключением сливов из ветки?

Question

Я бы хотел, чтобы разработчики не работали напрямую на багажнике.

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

Есть ли какие-либо правила для этого стиля использования SVN?

Answer 1

Ограниченный багажник фиксирует бота. Этот бот может выполнить беспорядочное слияние и передать в багажник. Я сделал именно это; это называется mergebot (лицензия MIT). Это демон и плагин Trac, чтобы предоставить возможность иметь филиал за билет. Документы тонкие, в углах есть проблемы, но в основном это работает.

Answer 2

Вы должны установить крючок фиксации, который обрабатывает эту ситуацию. Но я не уверен, действительно ли вы можете отделить фиксацию транка от слияния до магистрали (возможно, на основе svn: mergeinfo change) ... но я бы рекомендовал описать необходимость этого для разработчиков, вместо этого вынудив его ... и, кстати, скрипт фиксации должен быть написан и протестирован, и это усилия, которые, на мой взгляд, не нужны, если вы объясните это разработчикам.

Answer 3

Было бы намного проще, если бы ваши разработчики работали над багажником, но не фиксировали изменения «пока они не счастливы». Ваши разработчики могут более легко обновить свой код с совершенными изменениями, внесенными другими разработчиками.

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

Я запрещаю доступ к разработчикам Cobol в моем групповом доступе к соединительной линии SVN. Я сделал это, написав собственный подключаемый модуль Eclipse, который автоматически создает ветви и выполняет слияние обратно в магистраль.

Answer 4

Вы не можете этого сделать. Либо они могут писать в каталог, либо не могут.

Однако вы можете написать крюк предварительной фиксации, который обнаруживает, пытаются ли они сделать это и прервать, если это так.

Answer 5

Я не эксперт СВН любыми средствами, и ответ Даниила имеет смысл, так что я, возможно, нужен специалист SVN/WebDAV, чтобы сказать мне, почему это не будет работать:

This page описывает методы, используемые WebDAV различными командами SVN. И кажется, что вы можете «заблокировать» commit, rm, copy, mv и mkdir, отказавшись от разрешения пользователя на использование метода MKACTIVITY. Это будет по-прежнему позволяет diff, merge, checkout, ls, cat и т.д.

Итак все, что вам нужно будет сделать, это создать в вашей Apache конфигурации, <Limit> или <LimitExcept> директивы внутри <Location> директивы, соответствующей каталог соединительных линий. Я не проверял это, но это будет выглядеть примерно так:

<Location /repo/myproject/trunk> 
    ... 
    AuthType Digest 
    AuthName "Repository Admins Only" 
    AuthDigestProvider file 
    AuthUserFile "E:/Sites/.htpasswd-admin" 
    <Limit MKACTIVITY> 
     Require valid-user 
    </Limit> 
    ... 
</Location> 

И вы должны быть в состоянии гнезда, что внутри основного <Location> директивы вашего хранилища. Все это предполагает, что вы используете HTTPS для доступа к вашему репозиторию.

Answer 6

Чтобы разрешить сливаться только с багажником, вы можете использовать крюк предварительной фиксации, который пытается отличить сливки от обычных коммитов и отклоняет последний. Вы можете определить, является ли коммит слиянием, проверяя, изменит ли он свойство «svn: mergeinfo» на любом пути.This mailing list thread имеет два примера крючков, которые проверяют для mergeinfo. Эти примеры фактически пытаются обеспечить отсутствие отсутствия по определенным путям, но если вы отмените логику, вы можете сделать крючок, который принимает только слияния.

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

Более железным решением было бы ограничить доступ на запись к багажнику небольшому числу пользователей, которым вы доверяете, чтобы поступать правильно. Затем эти пользователи должны будут выполнить окончательный шаг «слияние обратно к багажнику» в каждом случае. Если разработчики уже слились с багажником в свою собственную ветку, то это окончательное слияние обратно тривиально, поэтому это не будет большой нагрузкой для ваших доверенных пользователей. Фактически, окончательное слияние может даже выполняться автоматическим процессом, когда разработчики отмечают свою ветку как «готовые к объединению». Я видел внутренние реализации такого автоматического процесса слияния, но я не знаю ничего общедоступного.

Answer 7

Ограничить доступ к /trunk с разрешениями SVN. Позвольте им читать, но не разрешайте писать. Назначьте одну роль «архитектора», которая может писать до /trunk. Разработчики должны будут сообщать архитектору, когда филиал готов, архитектор проведет тесты вручную, а затем объединится в /trunk.