Что это означает под атомарной фиксацией для системы управления версиями?


34

Одна из причин, по которой программисты предпочитают SVN, а не CVS, заключается в том, что первая допускает атомарные коммиты? Что это значит ?


Это может кому-то помочь , оно объясняет, что это такое (он использует git в качестве примера, но может быть применено для других VCS)
Fagner Brack

Ответы:


69

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

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

В SVN этого не произойдет - SVN либо зафиксирует все, что вы изменили, либо провалит весь набор изменений. Таким образом, вы никогда не оставите хранилище в нерабочем состоянии из-за проблем с фиксацией.


9
Важный результат этого является то, что если вы проверить в любом заданном состоянии , то результат всегда соответствует состоянию ( за исключением любых пользовательских ошибок , такие , как забыв совершить файл, конечно): Это либо из перед тем фиксации или после коммит и ничего промежуточного. В CVS это может быть «на полпути через коммит». Поведение SVN очень хорошо для таких вещей, как непрерывная интеграция. Для систем CVS эти системы использовали для обеспечения «тихого периода», когда они использовали только определенную проверку, если больше не фиксирует, где сделано определенное количество секунд / минут после проверки.
Йоахим Зауэр

2
Темные воспоминания об использовании CVS поразили меня, пока я читал это.
Шабун

9
@ Спайк - правда, но это умышленное действие. В CVS проблемы могут возникать не по вашей вине, в то время как в SVN вы должны над этим работать.
Майкл Кохн

3
@DanNeely - CVS фиксирует их один за другим. Вот почему вы получаете частичные коммиты - некоторые файлы проходят, а затем останавливаются, когда попадают в тот, который он не может зафиксировать (из-за конфликта). Я думаю, это результат того, что CVS изначально выросла из RCS.
Майкл Кохн

4
Также обратите внимание, что с помощью CVS, даже если вы не нажмете ошибку и все будет зафиксировано, кто-то с более быстрым соединением может обновить свое дерево исходных кодов в середине выполнения, оставив его в несовместимом состоянии. (И я ожидаю, что временные метки будут так же распределены, что попытка проверить дерево на дату / время, попавшее в середине коммита, даст аналогичные результаты.)
SamB

15

Это объясняется, например, в пока-CVS. Меня подорвала статья, написанная Энди Лестером :

Если я пытаюсь зафиксировать в Subversion, но один из файлов конфликтует или устарел, ни один из файлов не фиксируется. В CVS у вас есть полукоммитированный набор файлов, который вы должны исправить ПРЯМО СЕЙЧАС.

Тот факт, что CVS вынуждает программиста немедленно исправить слияние, настолько же непродуктивен, насколько это возможно. По сравнению с этим, возможность отложить / отменить / тщательно объединить изменения является существенным преимуществом.


Другие преимущества SVN перед CVS, описанные в статье выше:

  • Локальные версии всего, что вы делаете
     
    Если вы хотите использовать cvs diff, вы должны иметь возможность подключиться к вашему хранилищу. Нет сетевого соединения, нет диффузии. Subversion хранит локальные копии того, над чем вы работаете, поэтому svn diff будет работать отлично. Хотите начать все сначала? SVN Revert работает не подключен тоже.

  • Символические названия ревизий
     
    HEAD - это имя кончика ствола в CVS, но я всегда хотел иметь возможность сказать «-r-1», как я мог бы вернуться в дни PVCS. С CVS я должен сделать лог cvs на то, что я редактирую, и затем вычесть один. Это не весело. С Subversion я могу сказать svn diff -r PREV.

  • Отчет о реальном статусе
     
    В CVS единственный способ узнать, является ли что-то на сервере более новым, - это обновить cvs и надеяться, что все, что произойдет, не вызовет никаких конфликтов. С помощью команды svn status я получаю реальный статус, поэтому я могу видеть, есть ли конфликты, ДО того, как я сделаю обновление.

  • Полезная обработка конфликтов слияния
     
    В CVS, если есть конфликты, вы получаете маркеры конфликта в вашем файле. В Subversion вы получаете маркеры конфликта, ПЛЮС копию оригинального файла, предшествующего конфликту, ПЛЮС версию, пришедшую с сервера, ПЛЮС версию, которую вы первоначально редактировали. Затем вы должны явно разрешить svn имя-файла.txt, чтобы сообщить Subversion, что вы устранили проблему. Нет больше случайного возврата в CVS с маркерами конфликта, которые все еще там.


8

Это означает, что все изменения во всех файлах фиксируются в одной транзакции, поэтому либо все успешно, либо нет.

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


разве это не хорошо? В противном случае частичная фиксация приведет к несинхронизации файлов.
Компьютерщик

2
да сво хорошая вещь, частичные коммиты плохо
Ю.К..
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.