Какова ценность атомарных коммитов в Subversion?

Question

Я пытаюсь создать и следовать передовым методам управления версиями и наткнулся на ссылку на атомарные коммиты в Subversion. Поскольку я никогда не слышал об этом действии, у меня есть несколько вопросов об этом.

• Какова его цель?
• Когда его следует использовать?
• Чем он отличается от обычного коммита?
• Доступно ли это пользователям TortoiseSVN ? Если да, то как?

Answer 1

Специальных команд для атомарных фиксаций не существует. Каждый коммит в Subversion атомарный.

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

Это то же самое для TortoiseSVN, так как он основан на "нормальной" функциональности Subversion.

---

Ниже приводится выдержка из Subversion book :

Операция фиксации SVN публикует изменения любого количества файлов и каталоги как единое атомное сделка. В вашей рабочей копии вы может изменять содержимое файлов; Создайте, удалять, переименовывать и копировать файлы и каталоги; а затем совершить полный набор изменений как атомный сделка.

Под атомарной транзакцией мы подразумеваем просто это: либо все изменения происходят в хранилище, или ни один из них случается. Subversion пытается сохранить эта атомность перед лицом программы сбои, системные сбои, сеть проблемы и действия других пользователей.

Answer 2

Идея в том, что изменения в одном файле обычно связаны с изменениями в другом. Некоторые старые системы контроля версий на самом деле не обрабатывали несколько файлов за один коммит (как «атомарный коммит», как вы его называете) или делали это плохо.

Вам не нужно делать ничего особенного для этого. Так работает Subversion. Но с Subversion у вас есть возможность проверять по одному файлу за раз или делать все измененные файлы одновременно или где-то между ними.

Идея сделать несколько файлов одним коммитом заключается в том, что & mdash; в общем случае & mdash; вы должны иметь возможность проверить репозиторий в любой конкретной версии, и он, по крайней мере, будет скомпилирован и, надеюсь, запущен. Это важно в командах. Сейчас на практике это может не быть правдой в 100% случаев, но руководящий принцип обоснован.

Так что, если вы делаете один файл, все ваши изменения сразу или что-то между тем, что вы проверяете, должны иметь смысл как один коммит. Например, если вы исправили ошибку и вам нужно изменить 8 файлов, отметьте все эти 8 файлов как один коммит с сообщением о том, какую ошибку вы исправили и как вы ее исправили. Позже будет легче развернуться, если с ним возникнут проблемы.

Answer 3

«Атомная» в данном случае относится к атомной операции. Вы можете найти хорошее определение этого здесь: http://en.wikipedia.org/wiki/Atomic_operation

Все коммиты в SVN автоматически являются атомарными, поэтому вы получаете их бесплатно везде, где вы делаете коммит.

Answer 4

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

В SVN фиксация завершается успешно, и все 200+ файлов фиксируются за один раз, или фиксация завершается неудачно, и в хранилище вообще не было никаких изменений. (Больше нечего сказать по этому поводу. Просто так должно быть всегда.)

В CVS, в котором нет атомарных коммитов, может случиться так, что ваш коммит прервется после 150 файлов, потому что кто-то наткнулся на ваш сетевой кабель, а оставшиеся 50+ файлов не фиксируются, оставляя хранилище в промежуточном состоянии , Пока вы пытаетесь подключить сетевой кабель, кто-то из вашей команды проверяет другой набор изменений. Этот набор изменений не связан с теми, которые вы уже зарегистрировали, поэтому фиксация другого человека будет успешной. Однако изменения несовместимы. Теперь команда застряла с хранилищем, содержащим код, который даже не компилируется, не говоря уже о прохождении любого теста. Что еще хуже: у вас двоих есть менеджер команды, который дышит вам в шею, чтобы как можно быстрее исправить эти несовместимые изменения, чтобы остальная часть команды могла прекратить играть в Quake и вернуться к работе.

Удивительно, но такие сценарии не так маловероятны, как может показаться. Я был там несколько раз и получил свою паршивую рубашку.

Answer 5

Чтобы понять истинное использование атомарного коммита, прочитайте это о непрерывной интеграции:

http://en.wikipedia.org/wiki/Continuous_integration

Использование на самом деле означает, что вы можете отменить все изменения конкретного разработчика в случае проблем с интеграцией. Это очень мощная функция для сохранения целостности кода в хранилище.