Можно ли объединить несколько версий SVN в одну версию?

Question

Кто-то зарегистрировал 20 файлов как часть логической части выполняемой ими работы.

К сожалению, они сделали это как 20 отдельных коммитов.Это делает меня sad-panda

Есть ли способ очистить эти коммиты от репо, а затем повторно зафиксировать их за один раз?

В качестве альтернативы естьспособ связать эти наборы изменений вместе, чтобы предотвратить проверку кода одним из ревизий в середине?

Допустим, ревизии равны 1001-1020.То, что я хочу предотвратить, это то, что кто-то может объединить / разветвлять / пометить одну из нестабильных сломанных ревизий (т.е. 1001-1019).

Даже будучи в состоянии пометить / пометить эти 19 ревизий среднего уровня как не-mergeable / non-branchable будет полезно

Answer 1

Хотя я согласен с тем, что это плохая идея для разработчика, плохие ревизии в репозитории SVN (ревизии, приводящие к сбою сборки, сбоям модульных тестов и т. Д.) Являются общими и ожидаемыми.Вот почему мы используем непрерывную интеграцию.

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

Если вы хотите убедиться, что только хорошие ревизии идут в репо, вывероятно, должно быть два репозитория: один для фактической разработки, а другой, который объединяет несколько ревизий из репозитория dev, и в который вносятся изменения только после их проверки.Но я не вижу веских причин для этого.

Answer 2

Subversion записывает все, и до версии 1.8 (возможно) нет способа стереть прошлое.То есть, если вы не хотите делать дамп, фильтровать и загружать, чтобы удалить эти транзакции, а затем вручную повторить их как одну транзакцию.

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

Чтобы изменить свойство ревизии, вам нужно включить хук pre-revprop-change, чтобы вы могли изменить svn:log revprop, но этоне сложно сделать.Обычно я его устанавливаю, чтобы пользователь, который сделал коммит (svn: author) и admins (you), мог в любом случае изменить свойство svn: log.Таким образом, когда кто-то говорит мне, что он лукавит в своем сообщении о коммите (неправильный билет Jira и т. Д.), Я могу сказать им, чтобы он сам исправил это и прекратил беспокоить меня, когда я занят игрой в Angry Birds.