За кулисами

автоматизирована, и таким образом, большая часть слияний завершается автоматически, без вмешательства пользователя для разрешения конфликтов.

Когда вы думаете о том, что произойдет, когда вы зафиксируете изменения после слияния, опять вспомните правило «рабочий каталог — это ревизия, которую я сейчас зафиксирую». После завершения команды hg merge у рабочего каталога будет два родителя, они же и станут родителями новой ревизии.

Mercurial позволяет выполнять несколько слияний, но вы должны фиксировать результаты каждого слияния после каждого слияния. Это необходимо потому, Mercurial отслеживает только два родителя для ревизии и рабочего каталога. Хотя было бы технически возможно объединить несколько ревизий сразу, Mercurial считает что проще этого избегать. С многоходовым слиянием, есть риск ввести пользователей в заблуждение, отвратительным урегулированием конфликтов, и страшный беспорядок при слияния будет расти.

4.4.4. Слияние и переименование

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

Mercurial записывает метаданные, когда вы говорите ему выполнить переименование или копирование. Он использует эти данные во время слияния, чтобы правильно делать слияние. Например, если я переименую файл, а вы правите без переименования, когда мы объединяем наши работы файл будет переименован и ваш изменения будут внесены.

4.5. Другие интересные дизайнерские решения

В предыдущих разделах, я попытался осветить некоторые из наиболее важных аспектов проектирования в Mercurial, чтобы показать, что он уделяет особое внимание надежности и производительности. Тем не менее, внимание к деталям, не останавливается на достигнутом. Есть целый ряд других аспектов построения Mercurial, которые мне лично кажутся интересными. Я подробно опишу некоторые из них, отдельно от «большого списка» пунктов выше, так что если вам интересно, вы можете получить более полное представление о наборе идей, которые используются в четко разработанной системе.

4.5.1. Умное сжатие

Когда нужно, Mercurial хранит и основные файлы и дельты в сжатой форме. Для этого он всегда пытается сжать файл или дельту, но хранит сжатую версию только в том случае, если она меньше оригинальной.

Это означает, что Mercurial «правильно» обрабатывает ситуацию, когда сохраняется файл, который уже сжат, например, zip-архив или JPEG-изображение. Когда подобные файлы пережимаются второй раз, они обычно больше оригинала, так что Mercurial сохраняет оригинальный zip или JPEG.

Дельты между ревизиями сжатых файлов тоже обычно больше, чем сами файлы, и тут Mercurial тоже поступает «правильно». Если он видит, что размер такой дельты превышает размер файла, то он сохраняет сам файл, что опять же дает экономию дискового пространства по сравнению хранением только дельты файлов.

4.5.1.1. Сжатие при передаче по сети

При сохранении ревизий на диск, Mercurial использует алгоритм сжатия «deflate» (такой же, как и в популярном формате архивов zip), который сочетает хорошую скорость и приличный уровень сжатия. Однако, при передаче данных по сети, Mercurial распаковывает сжатые данные.

Если при передаче данных используется протокол HTTP, Mercurial переупаковывает весь поток данных целиком, используя алгоритм сжатия, который дает более высокую степень сжатия (алгоритм Burrows-Wheeler из архиватора bzip2). Комбинация из алгоритма и упаковки потока целиком (вместо сжатия каждой ревизии по отдельности) в значительной степени сокращает количество передаваемых данных, что в результате даёт лучшую производительность практически на любых видах сетевых подключений.

43