Camp (Commute And Merge Patches)

Commute And Merge Patches

Разработчики:	David Roundy
Написана на:	Haskell
Операционная система:	кроссплатформенное программное обеспечение
Лицензия:	GNU GPL
Веб-сайт	code.haskell.org

Camp (англ. Commute And Merge Patches) представляет собой систему контроля версий на основе теории patch аналогичной помощи darcs. Несмотря на то, что в настоящее время это отдельные проекты, проекты camp и darcs остаются близкими.

Camp names

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

Имена будут присвоены префиксу "P -" или " N -", в зависимости от того, являются ли они положительными или отрицательными, что означает, что подписанные имена могут использоваться в качестве имен файлов без необходимости беспокоиться о ведущих точек или тире интерпретируются специально любыми программами. Обратите внимание, что нечувствительной к регистру файловой системы будут иметь проблемы, используя имена как имена файлов, так что если вам нужно сделать после замены файлов с _а и т. д.

То, как мы на самом деле генерировать имена следующим образом.

Во-первых, при создании репозитория (init, get или put) мы вызываем систему.Время.getClockTime, который дает нам значение типа TOD 1221077558 958838000000. Затем мы преобразуем эти значения в базу 62 и объединяем их с тире, давая 1kDw3k-gSC6x2g. Мы храним это значение, имя repo, в репозитории.

Затем, когда patch записывается, мы делаем то же самое, чтобы получить вторую строку, скажем 1kDw6G-eR4aJ2. Мы также берем хэш, в формате и с алгоритмом, который должен быть определен, мета-данные патча, и преобразуем его в базу 62, скажем, d3R0pK84.

Наконец, мы объединяем эти три части с точками, давая 1kDw3k-gSC6x2g.1kDw6G-eR4aJ2.d3R0pK84. Если этот patch уже находится в нашем репозитории, то мы увеличиваем пикосекундный компонент времени создания patch и повторяем попытку. Иначе мы закончим.

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

Repo conversion

Существует один случай, когда вы хотите создать одно и то же имя: при преобразовании репозитория из, например, CVS в camp. Если вы преобразовываете repo в camp, и я преобразовываю в CVS repo в camp, то было бы неплохо, если бы мы создали такой же repo, и, следовательно, могли бы использовать патчи друг друга.

Существует два способа создания имен исправлений при этом. Один из них-принудить формат имен других VCS к формату имен лагерей. Обе стороны получат одну и ту же дату создания исправления и метаданные из другой VCS, которая оставляет только имя repo для создания. Если инструмент делает случайное имя repo, как и camp по умолчанию, то имена патчей будут отличаться; однако, используя имя инструмента в качестве имени repo, или спрашивая пользователя, что повторное имя должно быть, патчи получат те же имена.

Кроме того, помните, что camp не заботится о структуре имен (помимо ограничения набора символов, которые они используют), так что инструмент может использовать любую схему, которую он пожелает.

Конечно, какую бы схему ни использовал инструмент, необходимо быть осторожным, чтобы не генерировать два одинаковых имени во время преобразования репозитория!

Формат camp

Это описывает планируемый формат репозитория camp. Информация repo camp находится в подкаталоге _camp, который выглядит следующим образом:

_camp/ 

primary/

secondary/

settings/

Сейчас мы обсудим каждый подкаталог.

Первичный каталог

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

_camp/primary/

format

inventory

<files referred to by inventory, possibly in subdirectories>

формат содержит номер версии (в Data.Version sense) первичного формата.

Каждая строка инвентаря имеет формат.

Длина смещения файла name, где name - имя патча в репозитории. Контекст этого исправления - это набор имен исправлений в предыдущих строках файла. Представление патча находится в файле, от смещения байтов до смещения байтов + длина.

Можно было бы избежать необходимости переписывать весь файл инвентаризации только в обычном случае добавления, имея файл репозитория, содержащий имя файла инвентаризации и его размер. Затем добавление может быть сделано путем добавления к файлу инвентаризации с последующим перезаписью файла репозитория, и другие операции (например: (unpull)) напишет новый файл инвентаризации, а затем перепишет файл репозитория. Однако пока, по крайней мере, мы держим это просто.

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

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

Вторичный каталог

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

_camp/secondary/

format

pristine/

modification_times

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

Camp file-repository format

Camp также поддерживает второй формат репозитория, где репозиторий (или, чаще всего, частичный репозиторий) содержится в одном файле. После создания эти репозитории доступны только для чтения.

Причина в том, что это полезно для команды "camp send". Вместо того, чтобы, как и в darcs, иметь отдельную концепцию "patch bundle", и отдельную функцию "camp apply", чтобы применить их, мы можем просто использовать команду "camp pull". Мы получаем интерактивный выбор патч.

Преимуществ немного больше для camp, чем они будут за помощью darcs, поскольку camp не может разобрать формат, читабельный патч. Поэтому очень желательно, чтобы команда для применения отправленных исправлений позволяла сначала посмотреть на них. Конечно, команда "apply" может быть сделана, чтобы это позволить, но повторное использование команды "pull", которая уже делает это проще.

Darcs - это бесплатная кросс-платформенная система управления версиями с открытым исходным кодом, такая как git, mercurial или svn, но с совершенно другим подходом: сосредоточьтесь на изменениях, а не на моментальных снимках. Darcs предлагает более свободный способ работы, и более простой пользовательский интерфейс. Darcs не требует центрального сервера и прекрасно работает в автономном режиме.

Тестирования "camp get", на Debian amd64/Linux

Что было сделано?

Мы сравниваем:

camp	Код как из 2009-03-14, составленный с помощью ghc 6.11.20090308
darcs1	Релиз 1.0.9 помощью darcs, составленный с помощью ghc 6.11.20090308. Пришлось внести некоторые незначительные изменения (исправление как openFd называется, Выключить -Werror, использовать силу базового 3.0.3.0, связь с упаковок), чтобы получить его, чтобы построить, но ничего, что могло бы повлиять на результаты. В зависимости от агента пользователя, это использованием libcurl для загрузки по протоколу http.
darcs2	Релиз 2.2.0 помощью darcs, составленный с помощью ghc 6.11.20090308. В зависимости от агента пользователя, это использованием libcurl для загрузки по протоколу http.
git	Версия 1.5.6.3, из пакета Debian версии 1:1.5.6.3-1.1.

Мы используем 6 хранилищ:

darcs1	С "darcs get" локальный GHC HEAD repo, вплоть до " тэг 2009-03-13". Содержит 20,316 patches, которые состоят из 369,163 примитивных патчей.
darcs1hashed	это "darcs2 get --hashed darcs1 darcs1hashed"
darcs2	это "darcs2 convert darcs1 darcs2"
camp	это "darcs2camp darcs1; rm -r darcs" (darcs2camp создает и использует "darcs" каталог при преобразовании
campfrag	это "campfragment camp campfrag"
git	это "git-darcs-import darcs1 git; cd git; git update-server-info"

Репозиторий campfrag repo-это наихудший репозиторий camp: в файле патча есть случайное число (от 5000 до 6000) "x"s между двумя megapatches. Это означает, что для загрузки патчей camp необходимо сделать отдельный запрос на каждый патч.

Мы делаем семь тестов:

camp	Get " camp " repo with camp.
campfrag	Get "campfrag" repo with camp.
git	Get "git" repo with git.
darcs1	Get "darcs1" repo with darcs1.
darcs2.darcs1	Get "darcs1" repo with darcs2.
darcs2.darcs1hashed	Get "darcs1hashed" repo with darcs2.
darcs2.darcs2	Get "darcs2" repo with darcs2.

Каждый тест выполняется в локальной файловой системе и по протоколу HTTP к localhost. При выполнении теста мы делаем это один раз (игнорируя результаты), чтобы разогреть кэш, а затем еще пять раз, в которых мы записываем различные числа, используя "/usr/bin/time" и (за очевидным исключением git) GHC RTS.

Результаты тестирования:

• Во-первых, давайте посмотрим на прошедшее время локального get:

• Теперь давайте посмотрим на пиковое использование памяти, как записано GHC RTS (так что никаких цифр для git):

• Darcs2 требуется почти 600 м для darcs1 repo, что делает остальную часть графика почти нечитаемым. Реграфинг без него:

• Теперь давайте посмотрим на получение через HTTP.

• В этом случае darcs1 занимает более 25 минут, что делает график нечитаемым. Без него:

Интересно, что git больше не имеет преимущества. darcs2 (если не применять патчи) по-прежнему имеет край на camp, и есть больше разницы между компактным и фрагментированным camp репозиторием. Как и раньше, получение darcs2 в старом стиле darcs1 repo (и, следовательно, применение патчей) значительно медленнее.

• Посмотрим на использование памяти: