Управление версиями в Subversion Для Subversion 3 (в редакции 2345) Бен Коллинз-Сассман
жүктеу/скачать 2.13 Mb.
|
- Бұл бет үшін навигация:
- Хранилище
- Модели версионирования
- Проблема разделения файлов
- Модель Блокирование-Изменение-Разблокирование
- Модель Копирование-Изменение-Слияние
Глава 2. Основные понятияСодержание Хранилище Модели версионирования Проблема разделения файлов Модель Блокирование-Изменение-Разблокирование Модель Копирование-Изменение-Слияние Subversion в действии Рабочие копии Правки Как рабочие копии отслеживают хранилище Смешивание правок в рабочих копиях Обновления и фиксации отделены друг от друга Смешивание правок — это нормально Смешивание правок — это полезно Смешивание правок имеет ограничения Подводя итоги Эта глава представляет собой краткое, промежуточное введение в Subversion. Если контроль версий для вас в новинку, то эта глава специально для вас. Мы начнем с обсуждения основных понятий контроля версий, подойдем к основным идеям, лежащим в основе Subversion и покажем несколько простых примеров использования Subversion. Несмотря на то, что примеры в этой главе показывают людей делящих между собой набор исходников программы, помните, что Subversion может управлять набором файлов любого типа — она не ограничивается помощью компьютерным программистам.
Почему мы заостряем на этом внимание? Пока это звучит как определение типичного файл-сервера. И действительно, хранилище является разновидностью файл-сервера, однако не совсем обычного. Что делает хранилище Subversion особенным — это то, что он запоминает каждое внесенное изменение: любое изменение любого файла, равно как изменения в самом дереве каталогов, такие как добавление, удаление и реорганизация файлов и каталогов. При чтении данных из хранилища клиент обычно видит только последнюю версию дерева файлов. Но клиент также имеет возможность просмотреть предыдущие состояния файловой системы. Например, клиент может запросить такие данные как, «Что содержал этот каталог в прошлую среду?» или «Кто был последним изменявшим этот файл и какие вносились изменения?» Вопросы подобного типа основные для любой системы контроля версий: системы разработанной для записи и отслеживания изменений информации во времени.
Рассматриваемую ситуацию иллюстрирует Рисунок 2.2, «Проблема потери изменений». Допустим у нас есть два со-разработчика Гарри и Салли. Они вдвоем решили одновременно поредактировать один и тот же файл из хранилища. Если первым свои изменения в хранилище сохранит Гарри, то возможно, что (несколькими минутами позже) Салли может непреднамеренно перезаписать их своей новой версией файла. Несмотря на то, что версия файла Гарри не будет полностью потеряна (так как система помнит каждое изменение) внесенные Гарри изменения не будут отражены в новой версии файла Сэлли, потому что, начиная, она, не видела изменения Гарри. Работа Гарри фактически потеряна — или, по крайней мере, отсутствует в последней версии файла — по случайности. Как раз этой ситуации мы и хотим избежать! Рисунок 2.2. Проблема потери изменений 
Модель Блокирование-Изменение-РазблокированиеДля того, что бы несколько авторов не мешало друг другу многие системы управления версиями применяют модель блокирование-изменение-разблокирование. Эта модель запрещает одновременное редактирование файла несколькими пользователями. Эксклюзивность доступа гарантируется блокировками. Перед началом редактирования Гарри должен «заблокировать» файл. Если файл заблокировал Гарри, Салли уже не сможет его заблокировать и не сможет внести в него изменения. Ей остается только читать файл и ждать пока Гарри закончит свои изменения и снимет свою блокировку. После того как Гарри разблокирует файл, файл сможет получить Салли, заблокировать его и начать редактирование. Рисунок 2.3, «Модель блокирование-изменение-разблокирование» демонстрирует это простое решение. Рисунок 2.3. Модель блокирование-изменение-разблокирование 
Проблемой модели блокирование-изменение-разблокирование является то, что она немного ограниченная и часто доставляет неудобства пользователям:
Модель Копирование-Изменение-СлияниеSubversion, CVS и другие системы управления версиями пользуются моделью копирование-изменение-слияние в качестве альтернативы блокированию. В этой модели каждый пользовательский клиент связывается с хранилищем проекта и создает персональную рабочую копию — локальное отражение файлов и каталогов хранилища. После этого пользователи работают параллельно, изменяя свои личные копии. В конце концов, личные копии сливаются в новую, финальную версию. Обычно система управления версиями помогает в слиянии, но, разумеется, за его корректное выполнение отвечает человек. Вот пример. Скажем и Гарри и Салли создали копированием из хранилища рабочие копии одного и того же проекта. Они работают одновременно и в своих рабочих копиях вносят изменения в один и тот же файл А. Первой свои изменения в хранилище сохраняет Салли. Когда позже Гарри попытается сохранить свои изменения, хранилище проинформирует его о том, что его файл А устарел. Другими словами, файл А каким то образом изменился со времени, когда он его последний раз копировал. Поэтому Гарри просит свой клиент слить любые изменения из хранилища в его рабочую копию файла А. По счастливому совпадению, изменения Салли не перекрываются с его собственными; после объединения обоих наборов изменений он сохраняет свою рабочую копию обратно в хранилище. Рисунок 2.4, «Модель копирование-изменение-слияние» и Рисунок 2.5, «Модель копирование-изменение-слияние (продолжение)» показывают этот процесс. Рисунок 2.4. Модель копирование-изменение-слияние 
Рисунок 2.5. Модель копирование-изменение-слияние (продолжение) 
А что если изменения Салли перекрываются с изменениями Гарри? Что тогда? Эта ситуация называется конфликтом и, как правило, это не является большой проблемой. Когда Гарри просит свой клиент слить последние изменения хранилища в рабочую копию, его копия файла А как-то помечается как находящаяся в состоянии конфликта: у него будет возможность видеть оба набора конфликтующих изменений и вручную сделать между ними выбор. Помните, что ПО не может автоматически разрешать конфликты; только человек способен к пониманию и выполнению осмысленного выбора. Разрешив вручную перекрывающиеся изменения - возможно, после обсуждения с Салли — он может безопасно сохранить объединенный файл обратно в хранилище. Модель копирование-изменение-слияние может выглядеть немного хаотично, однако, на практике она отлично работает. Пользователи могут работать параллельно, не тратя время на ожидание друг друга. При работе над одними и теми же файлами оказывается, что большинство параллельно вносимых изменений совсем не перекрываются; конфликты бывают редко. И время, которое было потрачено на разрешение конфликтов значительно меньше времени отнимаемого блокирующей системой. Наконец, все сходится к такому критическому фактору, как взаимодействие пользователей. При плохом взаимопонимании увеличивается количество как синтаксических, так и семантических конфликтов. Нет системы, которая может повысить уровень взаимопонимания, и нет системы, которая может определять семантические конфликты. Не стоит возлагать большие надежды на то, что блокирующая система лучше защищена от конфликтов; на практике блокирование снижает продуктивность как ничто другое. Когда блокирование необходимо Несмотря на то, что модель блокирование-изменение-разблокирование названа, в целом, губительной для командной работы, все-таки есть моменты когда блокирование уместно. Модель копирование-изменение-слияние основывается на предположении о том, что файлы контекстно-объединяемы: это так если большинство файлов в хранилище — текстовые файлы (например исходный код программы). Но для файлов бинарных форматов, таких как графические или звуковые, как правило не возможно объединить конфликтующие изменения. В таких ситуациях пользователям действительно необходимо быть внимательными при изменении файла. Без раздельного доступа кто-то может впустую потратить время на изменения, которые в конце концов будут потеряны. Так как и CVS, и Subversion, — в первую очередь системы типа копирование-изменение-слияние, то в них обоих признается необходимость блокирования определенных файлов и предлагаются механизмы для этого. См. «Locking». жүктеу/скачать 2.13 Mb. Достарыңызбен бөлісу:
|
