Понять ветвления

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

Триггеры perforce

Наша разработка ведется очень демократично. Мы пишем под FreeBSD (исторически и лицензионно сложилось), используем кодировку koi8-r (тоже исторически сложилось, FreeBSD не очень то дружит с UTF-8 и по сей день).

Но в то же время мы не навязываем разработчикам никаких условий... Каждый работает так, как ему комфортнее. Жить под FreeBSD - я не пожелаю и врагу (ну вы уже знаете, как я ее не люблю :) ). Наши разработчики пользуются своими любимыми редакторами, сидят в своих любимых системах с разными локалями и интерпретациями концов строк.

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

Ветвления в бранче

Все-таки это зло.

Mercurial позволяет двум разработчикам независимо сделать push, что приведет к тому что в бранче на сервере получится ветвление. Но что делать третьему разработчику, который это вытягивает? Заниматься слиянием? Да он вообще не в курсе что там куда.

Он мог бы выбрать себе, предположим, одну из ветвей... Но в это же самое время хозяин этой ветви может слить ее с другой и третий разработчик опять останется не у дел, где-то в своей отдельной ветке.

Назад, в будущее...

Закоммитил не функционирующие изменения. Причем привык сразу делать hg push, чтобы не забыть это сделать позже. И только потом выяснил что все сломалось, надо выкинуть эти изменения и начать сначала. Но меркуриал немного разочаровал.

hg rollback можно делать только один раз и только до того как ты сделал push, при этом ревизия совершенно исчезает.

hg backout позволяет сделать откат, при этом добавляя еще одну ревизию.

Записал в дневнике: Достаточно переместить хед на одну ревизию назад и дальше пойти уже от нее. Тот хед - пусть болтается как тупиковая ветвь. Вполне естественно. Хотя может быть я что-то не понимаю.

Человеческое лицо subversion - 2

Git очень плохо дружит с proxy. Его можно заставить работать с прокси, но после этого git-svn все равно валится по сигналам после каждой ревизии.

В связи с вышесказанным извлечь FreeBSD на работе не получилось, поэтому эксперименты спокойно буду проводить дома.

Итак, продолжение эксперимента...

Человеческое лицо Subversion

Людям, поработавшим с децентрализованными системами контроля версий, нет необходимости перечислять все вкусности - которые они дают. Но, к сожалению, в сети много проектов, которые используют морально устаревшие централизованные системы контроля. Ладно бы еще subversion, но до сих пор нередко использование cvs.

И вот я, как настоящий джедай, решил затянуть к себе историю развития FreeBSD... Мне важна не сама история, больше всего меня интересует новейшая история, но все DVCS, по моим сведениям, не умеют вытягивать историю частично.

Тащить стабильные ветки - совершенно неинформативно, Весь чейнджлог содержит только собщения о мердже. Следовательно надо тащить к себе транк, который в репозитории FreeBSD традиционно по cvs'овски называется HEAD.

Проблема в том что история FreeBSD - богатая, 200 тысяч ревизий. И как выяснилось, не всякая DVCS долетит до середины репозитория FreeBSD. Решил немного сравнить mercurial и git в этом плане.

CVCS мертв?

Было время, когда никто не слышал про бранчи. Собственно и система контроля была одна - cvs. Нет две, еще был rcs, но это помоему совсем уж дедушка систем контроля версий.

Но времена меняются очень быстро. Subversion за считанные годы просто похоронил cvs. Да и его скоро отправят на свалку истории...

Несколько дней назад упал savannah.gnu.org. Вследствии отказа RAID-массива содержимое проектных баз было безвозвратно утеряно. Последний нормальный бекап - месячной давности (sic!). Какой же у них рейд, если всеравно все рухнуло?

И вот, бедные владельцы проектов, которых угораздило хранить свои проекты в cvs/svn вынуждены по крохам восстанавливать содержимое баз (буквально с помощью сообщества).

И вот после этого подумаешь - всетаки умные люди не зря придумали DVCS? Скорее бы уже google code поднял меркуриал, я мигрирую.

Собственно для меня история проекта имеет достаточно незначительную ценность. Я просто не знаю зачем она мне может понадобиться. Но прикольно то, что с 2002 года sourceforge бережно хранит мою базу. И только.

В корпоративном плане история несомненно нужна. Хотя бы для того, чтобы выяснить - какой же идиот написал этот код?

Ценность бранчей пока еще ясна не всем, возможно по причине использования устаревших средств, которые с этими самыми бранчами не особо дружат. Я вот точно не знаю, последние версии SourceSafe научились делать бранчи? Perforce например делает вид что умеет это делать, но при этом историю теряет. То есть новый бранч - новая история. И на вопрос из предыдущего абзаца ответить уже не удается.

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

Собственно смысл этого понятен, при переименовании файла перфорсу хочется сэкономить место в базе и связать новый файл со старым (по идентичности содержимого). Только мне то какое до этого дело? Кроме того я явно говорю ему что этот файл я синтегрировал из этого - отслеживай елыпалы.

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

А savannah.gnu.org конечно круто опозорился. Все срочно переходят на hg/git на других площадках.

Производительность VCS

Читая новости OpenNet, наткнулся на несколько ссылок: bzr, git, and hg performance on the Linux tree, git/bzr historical performance comparison, и несколько более косвенно Distributed Version Control Systems: A Not-So-Quick Guide Through. У меня так и не дошли руки до полноценного исследования производительности. В данных обзорах немного расстраивает лишь отсутствие monotone.

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

Но чтобы оценить изменение рабочего каталога относительно HEAD репозитория, необходимо сравнить содержимое файлов, ну это в идеальном варианте, все остальные варианты оставляют шансы на ошибку. Причем нам главное знать факт изменения файла. Изменение длины явно говорит о том, что файл изменился, так же как и изменение хеша. Но с другой стороны изменение времени вообще ни о чем не говорит, а совпадение хеша вовсе не говорит о том, что файлы идентичны. Может быть именно последний момент подталкивает некоторые системы контроля оперировать не хешами а номерами?

Но раз уж системы оперируют хешами как версиями файлов, видимо приходится принять условие, что совпадение хеша подтверждает совпадение файла. Но проблема в том, что рассчет хеша всех файлов дерева linux занимает порядка минуты, ну если соптимизировать - ну 40 секунд к примеру. И становится непонятным, как git, bzr и hg умудряются показывать статус за считанные секунды (1-5 сек).

Вероятно, они всетаки доверяют времени, и файлы с неизменным временем автоматически считаются неизмененными. Вообще я не склонен доверять времени, время может съехать, ИМХО Makefile работают совсем не правильно. :) Ну это наверное мое извечное всеотрицание. А если рассуждать трезво, то меня вовсе не радует перспектива ждать по 40 секунд для просмотра статуса изменений. Поэтому использование таймстампов файлов - это меньшее из зол.

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

Ответственность за изменения...

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

Начнем с глобальных мотивов. Если взять большой открытый проект типа linux, то там ситуация такова, что конкретные изменения вносят тысячи людей, Линус не обязан им доверять и может вообще не подозревать об их существовании (нет необходимости импортировать ключи), потому, что эти изменения попадают к нему через доверенных лиц, которые, как бы, берут на себя ответственность за эти изменения. Собственно git и не поддерживает (во всяком случае в стандартной поставке) подписывания каждого изменения, там есть только подписывание меток.

В более ограниченных проектах ситуация с доверием возможна, если бы не несколько но. При единственной ветви разработки никаких проблем нету. (CVCS?) Проблемы начинаются при ветвлениях.

Предположим что существует некая ветвь разработки a. от нее создается ветвь b, и обе ветви некоторое время развиваются независимо... a1 -> a2 -> ... an, b1 -> b2 -> ... bn. Естественно, что каждый набор изменений подписан кем-то.

Теперь ветвь b сливается с ветвью a.

Первый путь (mercurial вроде так поступал), Это когда изменения сливаются в рабочей копии и формируется версия a(n+1), которая потом коммитится в ветви a. Но в этом случае получается что ни подписанные истории изменений, не авторство их не попадает в ветвь a. И этическая сторона в этом месте такова, что нельзя ссылаться на автора изменений (annotate, log), потому что его подписи нигде нету. То есть ситуация ровно как в ядре линукс, автор слияния берет на себя ответственность за все вносимые изменения.

Я, как человек сведующий в криптографии понимаю что любое изменение подписанных данных автоматически приводит к недействительности подписи. Но теоретически, если изменения ветви b производились в файлах не изменяемых в ветви a, то историю изменений можно перенести из b, при этом новая версия (дерево файлов) всеравно подписывается автором слияния, но изменения по конкретным файлам имеют изначальное авторство. Но любой конфликт нарушает эту идиллию коренным образом, поскольку любое постороннее изменение файла исключает возможность применения вливаемых изменений, и ситуация сводится к предыдущей.

файл1: a -> b1 -> ... bn (HEAD of a)
файл2: a -> a1 -> ... an (HEAD of a)

Это справедливо только для бинарных дельт, diff'ы можно было бы накатывать и на посторонние изменения, если не учитывать тот факт что при подписывании изменений стоит обращать внимание и на содержимое исходного файла, иначе как можно дать гарантию, что изменение не деструктивное?

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

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

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

К тому же при большом количестве участников необходимо распространять и ключи...

Может я опять чего-то не учитываю? Что-то еще хотел написать да забыл. завтра вспомню.

PS: Вот, спустя неделю, кое что вспомнил. Подписывать надо не наборы изменений, а состояние версии. Но это требует от системы контроля целостности состояний, то есть версия должна фиксировать содержимое всех файлов проекта (как в monotone). Что касается git, то его изменения ИМХО кумулятивны, и вообще не понимаю каким боком туда прикручивают цифровые подписи, а ведь прикручивают же, или я опять ошибаюсь?

Идеальная система контроля версий...

Наверное нет в жизни счастья, или просто характер такой непримиримый. Хочется, чтобы все было так как хочется :)... Но проблема в том, что у других людей и ход мыслей зачастую отличается от моих, и, как следствие, программы они пишут не такие, как я хочу. :(

А сам я все написать тоже не могу, но мне ничего не мешает думать об этом.

Собственно к чему это я. Во многом я согласен с Линусом Торвальдсом. Распределенные системы контроля версий удобны. Но немаловажно и то, что система контроля версий должна работать быстро и занимать мало места для хранения истории.

Но в то же время git имеет явное ориентирование на патчи. У меня даже сложилось впечатление что версии в git - это патчеобразные наборы изменений, то есть одна ревизия git описывает изменения только в ограниченном количестве файлов. В то время как мое скромное мнение на этот счет таково, что версия должна характеризоваться полным состоянием дерева файлов. В принципе, в своем мнении я не одинок, так делает к примеру monotone.

Но у monotone есть один серьезный недостаток, о котором я уже упоминал - он медленный. Постановка на контроль 24.5к файлов (ядро линукс - мой любимый тестовый набор) занимает В общей сложности 3 минуты. Хм... что-то изменилось, кажется раньше он был значительно медленнее.

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

И самое гавное - бранчи - это легковесное ветвление. Создание бранчей должно быть возможно даже для минимальных изменений. С последующим слиянием и удалением бранча. Вот какраз с последним у некоторых систем наблюдаются проблемы. Удаление бранчей поддерживают далеко не все. Monotone, mercurial вообще не умеют удалять бранчи (тяжеловесные бранчи?), bazaar вообще всю поддержку бранчей сводит к клонированию - иногда это удобно, иметь доступ к двум ветвям одновременно, но иногда и не нужно. git в этом плане более гибок, только не совсем понимаю зачем при клонировании он создает origin бранчи? Логика разработчиков такая наверное.

Гораздо проще клонировать базу как есть, обратный слив изменений в любом случае должен осуществляться в отдельные ветви (как в monotone)... Можно даже, например, при клонировании указывать название ветви, и клонировать только ее.

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

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

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

PS: Я вот наивно подумал, что git с помощью rebase мог бы позволить внести в историю предыдущие версии проекта, как бы не так. С удалениями/добавлениями он разобраться не в силах - просит ручками разбирать. Хотя как просто - одно состояние, другое состояние - сделай diff. Ан нет.

PPS: тот же git по умолчанию считает что каждый файлик на коммит надо добавлять индивидуально (логика ориентирована на патчи, опять таки). Хотя мне что-то подсказывает что если я говорю commit - все изменения надо вносить, если мне что-то не надо вносить, я исключу руками. но это конечно определяется подходом.

PPS: Как в git посмотреть список игнорируемых файлов? 'git ls-files --ignored' требует exclude pattern... не понимаю смысла.

Хотя может быть я просто что-то не понимаю? :)

Контроль версий с mercurial...

У каждой системы контроля версий своя логика работы, и наверное поэтому они плохо позволяют обмениваться данными друг с другом. Я прекрасно понимаю мысли разработчиков Subversion, которые, создав легкое копирование, отказались одним махом и от тэгов и от бранчей. Но логика подсказывает что бранчи всетаки не такие. Бранчи - это как бы третье измерение контроля версий. Первое измерение - файлы и каталоги, второе - время (история изменений). В Subversion они как бы развернули третье измерение - независимые ветви разработки на первое.

И вот недавно я решил поглядеть на Mercurial.

Вообще я нигиллист наверное. Я и в Subversion никогда не пользовался традиционными trunk/tag/branch, благо это распределение чисто условно. Но вот думаю - как можно содержимое репозитория с такой логикой корректно перенести в репозиторий с правильной? (чем женская логика отличается от железной?) Дык почитай почти никак. Можно перенести все дерево, но функциональность бранчей пропадет. Однако ближе к теме...

Mercurial весьма близок к git. У них одинаковая логика работы, они оба хранят базу изменений непосредственно в рабочем каталоге проекта. В отличии от такого же распределенного monotone, который требует отдельную базу. И еще одно выгодное отличие от monotone в том, что и mercurial и git поразительно быстры. mercurial наверное более дружелюбен к пользователю тем, что имеет меньший набор команд. git в принципе имеет более компактную базу, но чтобы добиваться этой компактности - базу надо специальной командой паковать.

Помню, как в былые времена cvs, доступ к которому можно было получить только по cvs или по ssh протоколу многочисленные проблемы с доступом к репозиторию с работы. Но эти времена прошли. Subversion работает практически как угодно. Не знаю как работает git, но mercurial можно установить просто на http хостинг, правда для вливания в него изменений всеравно придется пользоваться ssh, но какой http хостинг ныне обходится без ssh?

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

Но возвращаясь к ранее высказанной мысли - взаимодействие с svn в mercurial в принципе есть. Для этого существуют различные плагины как для импорта, так и для синхронизации. Но не слишком ли разная у них логика работы? Для svn я буду и дальше использовать распределенный svk.

PS: Кстати в mercurial есть замечательная команда - addremove, которая позволяет добавить на контроль все, что не добавлено и удалить все что отсутствует в рабочей копии. Даже в git для этих целей приходится немного нелогично изголяться - git add * - добавить все неподконтрольное; git commit -a - при коммите удалить все отсутствующее.

Хотя, конечно, для разработки это достаточно бесполезная фича, но эта фича достаточно интересна тем, кто формирует свои проекты из имеющегося открытого ПО.

Массивные изменения с контролем версий.

Обычно изменения исходников достаточно немногочисленны и разобраться с ними вручную не составляет труда. Но иногда возникают сложности...

Я сейчас строю небольшой дистрибутивчик, встраиваемое решение. Состоит он из ядра linux, busybox и одной программочки из util-linux. Минимум. В оригинале система была построена на базе uClinux, но сделать с ним что-то было весьма не просто, старый, ничего не собирается. Поэтому я его распотрошил, выдернул ядро 2.6.11.8 со всякими патчами как было, взял свежий busybox, свежий util-linux, написал Makefile который все быстро билдит почти с учетом всех зависимостей.

Busybox конечно глючная штука. никак с ним не поборюсь, но основные утилиты работают. Самое страшное для меня - это ядро. Надо отметить, что погружал я его в систему контроля версий почастям... сперва ядро 2.6.11.8, потом hsc0 патч, потом погрузил имеющуюся версию и теперь могу отделить патч от разработчика платы в чистом виде. Кроме того на него уже наложен мой патч на шифрование, но там все просто.

От проекта требуется в первую очередь работать с USB, причем не только как хост, но и как девайс. Вот с этим какраз возникают проблемы, которые заключаются в том, что не все флешки одинаково качественны. И не всякое чтение дойдет до середины флешки.

Это была присказка.. или как говорят - преамбула... теперь наступила амбула.

Поскольку в текущем состоянии все работает, имеет смысл перейти на всежее ядро, предполагаю, что в последних ядрах USB стек сильно отличается от ядра 2.6.11.8, которое выпущено в 2005 году. Если мне не изменяет память USB 2.0 тогда только зародилось.

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

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

$ svn status | grep \! | sed -e 's/\!//g' | xargs svn rm
$ svn status | grep ? | sed -e 's/\?//g' | xargs svn add
$ svn commit

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

Контроль версий с svk...

Не знаю, кто как, но я без контроля версий вообще не могу.

Можно много спорить о том, какие из систем контроля версий лучше.
Но я последнее время пользуюсь SVK. Эта замечательная распределенная система контроля умеет зеркалировать cvs, subversion, perforce... Но даже если сервер зеркалируемой системы контроля недоступен, это не мешает вносить изменения в локальный репозиторий.

Я бы предпочел monotone, но никто из хостеров проектов его пока не поддерживает (хотя может быть уже поддерживает? когда я последний раз этим интересовался?).

Но речь не о том... Недавно, с тех пор, как занялся с упоминаемым ранее армом) у меня возникла необходимость ковыряться в ядре, или того хуже - в uClinux... И вот тут то SVK меня подвел... чтобы загрузить в него проект такого размера (add, commit) нужно несколько часов (если не дней)... Хотя с незначительными изменениями в больших проектах он справляется без особых тормозов.

Его конечно трудно за это винить, он написан на perl... К тому же массовый влив исходников - не самое типичное занятие для системы контроля версий. Но, тем не менее, это вынудимо меня использовать более шуструю систему контроля.

PS: К тому же всеравно, по работе может потребоваться сервер с системой контроля, чего svk не умеет в принципе - он по большей части frontend...