progit · Morganov · Oct 8, 2022 · Mar 10, 2021 · Oct 8, 2022 · Oct 8, 2022
diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc
@@ -5,9 +5,9 @@
 Система контроля версий -- это система, записывающая изменения в файл или набор файлов в течение времени и позволяющая вернуться позже к определённой версии.
 Для контроля версий файлов в этой книге в качестве примера будет использоваться исходный код программного обеспечения, хотя на самом деле вы можете использовать контроль версий практически для любых типов файлов.
 
-Если вы графический или web-дизайнер и хотите сохранить каждую версию изображения или макета (скорее всего, захотите), система контроля версий (далее СКВ) -- как раз то, что нужно.
+Если вы графический или web-дизайнер и хотите сохранить каждую версию изображения или макета (скорее всего, захотите), система контроля версий (далее VCS) -- как раз то, что нужно.
 Она позволяет вернуть файлы к состоянию, в котором они были до изменений, вернуть проект к исходному состоянию, увидеть изменения, увидеть, кто последний менял что-то и вызвал проблему, кто поставил задачу и когда и многое другое.
-Использование СКВ также значит в целом, что, если вы сломали что-то или потеряли файлы, вы спокойно можете всё исправить.
+Использование VCS также значит в целом, что, если вы сломали что-то или потеряли файлы, вы спокойно можете всё исправить.
 В дополнение ко всему вы получите всё это без каких-либо дополнительных усилий.
 
 ==== Локальные системы контроля версий
@@ -17,45 +17,45 @@
 Данный подход очень распространён из-за его простоты, однако он невероятно сильно подвержен появлению ошибок.
 Можно легко забыть в каком каталоге вы находитесь и случайно изменить не тот файл или скопировать не те файлы, которые вы хотели.
 
-Для того, чтобы решить эту проблему, программисты давным-давно разработали локальные СКВ с простой базой данных, которая хранит записи о всех изменениях в файлах, осуществляя тем самым контроль ревизий.
+Для того, чтобы решить эту проблему, программисты давным-давно разработали локальные VCS с простой базой данных, которая хранит записи о всех изменениях в файлах, осуществляя тем самым контроль ревизий.
 
 .Локальный контроль версий
 image::images/local.png["Диаграмма локального контроля версий"]
 
-Одной из популярных СКВ была система RCS, которая и сегодня распространяется со многими компьютерами.
+Одной из популярных VCS была система RCS, которая и сегодня распространяется со многими компьютерами.
 https://www.gnu.org/software/rcs/[RCS^] хранит на диске наборы патчей (различий между файлами) в специальном формате, применяя которые она может воссоздавать состояние каждого файла в заданный момент времени.
 
 ==== Централизованные системы контроля версий
 
 (((контроль версий,централизованный)))
 Следующая серьёзная проблема, с которой сталкиваются люди, -- это необходимость взаимодействовать с другими разработчиками.
-Для того, чтобы разобраться с ней, были разработаны централизованные системы контроля версий (ЦСКВ).
+Для того, чтобы разобраться с ней, были разработаны централизованные системы контроля версий (Centralized Version Control System, далее CVCS).
 Такие системы, как CVS, Subversion и Perforce, используют единственный сервер, содержащий все версии файлов, и некоторое количество клиентов, которые получают файлы из этого централизованного хранилища. (((CVS)))(((Subversion)))(((Perforce)))
-Применение ЦСКВ являлось стандартом на протяжении многих лет.
+Применение CVCS являлось стандартом на протяжении многих лет.
 
 .Централизованный контроль версий
 image::images/centralized.png["Диаграмма централизованного контроля версий"]
 
-Такой подход имеет множество преимуществ, особенно перед локальными СКВ.
+Такой подход имеет множество преимуществ, особенно перед локальными VCS.
 Например, все разработчики проекта в определённой степени знают, чем занимается каждый из них.
-Администраторы имеют полный контроль над тем, кто и что может делать, и гораздо проще администрировать ЦСКВ, чем оперировать локальными базами данных на каждом клиенте.
+Администраторы имеют полный контроль над тем, кто и что может делать, и гораздо проще администрировать CVCS, чем оперировать локальными базами данных на каждом клиенте.
 
 Несмотря на это, данный подход тоже имеет серьёзные минусы.
 Самый очевидный минус -- это единая точка отказа, представленная централизованным сервером.
 Если этот сервер выйдет из строя на час, то в течение этого времени никто не сможет использовать контроль версий для сохранения изменений, над которыми работает, а также никто не сможет обмениваться этими изменениями с другими разработчиками.
 Если жёсткий диск, на котором хранится центральная БД, повреждён, а своевременные бэкапы отсутствуют, вы потеряете всё -- всю историю проекта, не считая единичных снимков репозитория, которые сохранились на локальных машинах разработчиков.
-Локальные СКВ страдают от той же самой проблемы: когда вся история проекта хранится в одном месте, вы рискуете потерять всё.
+Локальные VCS страдают от той же самой проблемы: когда вся история проекта хранится в одном месте, вы рискуете потерять всё.
 
 ==== Распределённые системы контроля версий
 
 (((контроль версий,распределённый)))
-Здесь в игру вступают распределённые системы контроля версий (РСКВ).
-В РСКВ (таких как Git, Mercurial, Bazaar или Darcs) клиенты не просто скачивают снимок всех файлов (состояние файлов на определённый момент времени) -- они полностью копируют репозиторий.
+Здесь в игру вступают распределённые системы контроля версий (Distributed Version Control System, далее DVCS).
+В DVCS (таких как Git, Mercurial, Bazaar или Darcs) клиенты не просто скачивают снимок всех файлов (состояние файлов на определённый момент времени) -- они полностью копируют репозиторий.
 В этом случае, если один из серверов, через который разработчики обменивались данными, умрёт, любой клиентский репозиторий может быть скопирован на другой сервер для продолжения работы.
 Каждая копия репозитория является полным бэкапом всех данных.
 
 .Распределённый контроль версий
 image::images/distributed.png["Диаграмма распределённого контроля версий"]
 
-Более того, многие РСКВ могут одновременно взаимодействовать с несколькими удалёнными репозиториями, благодаря этому вы можете работать с различными группами людей, применяя различные подходы единовременно в рамках одного проекта.
+Более того, многие DVCS могут одновременно взаимодействовать с несколькими удалёнными репозиториями, благодаря этому вы можете работать с различными группами людей, применяя различные подходы единовременно в рамках одного проекта.
 Это позволяет применять сразу несколько подходов в разработке, например, иерархические модели, что совершенно невозможно в централизованных системах.
diff --git a/book/01-introduction/sections/history.asc b/book/01-introduction/sections/history.asc
@@ -4,7 +4,7 @@
 
 Ядро Linux -- это достаточно большой проект с открытым исходным кодом.(((Linux)))
 Большую часть времени разработки ядра Linux (1991–2002 гг.) изменения передавались между разработчиками в виде патчей и архивов.
-В 2002 году проект ядра Linux начал использовать проприетарную децентрализованную СКВ BitKeeper.(((BitKeeper)))
+В 2002 году проект ядра Linux начал использовать проприетарную децентрализованную систему контроля версий BitKeeper.(((BitKeeper)))
 
 В 2005 году отношения между сообществом разработчиков ядра Linux и коммерческой компанией, которая разрабатывала BitKeeper, прекратились, и бесплатное использование утилиты стало невозможным.
 Это сподвигло сообщество разработчиков ядра Linux (а в частности Линуса Торвальдса -- создателя Linux) разработать свою собственную утилиту, учитывая уроки, полученные при работе с BitKeeper.(((Линус Торвальдс)))