Оставлено ради обеспечения совместимости с… человеком

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

Английский язык одновременно очень лаконичный и емкий. И слово «fossil», в качестве основного перевода которого в словарях указывается «ископаемое», далеко не всегда имеет сугубо негативный смысл. Хотя бы потому, что в перечне его значений есть еще и техническое – «нечто, оставленное для обеспечения совместимости».

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

Итак, мы будем говорить о программном продукте инструментального назначения, ориентированном на основную массу программистов, – о Fossil, системе конфигурационного управления. Большинство читателей наверняка знают, что все, попадающее в категорию Software Engineering, во-первых, ужасно малопонятно и потому кажется сложным, во-вторых – действительно очень сложно реализовано, и наконец, в-третьих – масштабно. Увы, «конфигурационное управление» (к слову, автору статьи такой перевод Software Configuration Management не нравится категорически, поэтому впредь мы будем оперировать понятием «управление конфигурациями ПО») относится к этой печально известной категории, в которой все затянуто густым туманом заумных определений, а все серебряные пули – фальшивые (что сразу настораживает – в таких местах, очевидно, должно быть куда больше монстров, чем смелых хороших парней). Именно по этой причине можно слышать частые сетования – дескать, действительно, мало у нас (в индустрии) «хороших парней», умеющих использовать и использующих в повседневной работе инструменты Software Engineering. Да, действительно немного. По разным оценкам, не больше 20%. Но ведь это не потому, что оставшиеся 80% – «плохие парни». Попробуйте прочесть от корки до корки любой документ с ключевыми словами Software Configuration Management в названии и убедитесь самостоятельно в том, что второй подобный документ вам читать уже не захочется (даже если чтение подобных документов – ваша работа): «Конфигурационное управление формально определяется глоссарием IEEE 610 как дисциплина приложения технических и административных указаний (инструкций) и контроля (надзора) для: идентификации и документирования функциональных и физических характеристик элементов конфигураций, контроля (управления) изменений этих характеристик, записи (сохранения) и ведения отчетности по обработке изменений и статусу их реализации, а также проверки (верификации) соответствия заданным требованиям» (software-testing.ru/lib/se/configuration-management/). Если же вы попытаетесь самостоятельно освоить какой-либо из продуктов, относящихся к этой категории, вы столкнетесь в первую очередь с... толщиной книг. Одно второе издание «Essential CVS» из «зверинца O'Reilly» (культовая серия книг с разными зверушками на обложках) приветливо встретит вас почти четырьмя с половиной сотнями страниц. И что самое веселое – одной этой книги будет мало. Потому что по ходу дела непременно выяснятся «маленькие нюансы», и окажется нужным развертывать не только собственно систему управления конфигурациями ПО, но и разные сопутствующие подсистемы – или веб-сервер, или СУБД, или и то, и другое одновременно (а о груде мелких инструментальных средств вообще не приходится говорить). В результате же окажется, что для небольшой команды программистов, занятой в небольшом проекте (само собой, понятие «небольшой» здесь весьма условно), все эти накладные расходы не сильно-то и окупаются. Реакция на подобное законна и предсказуема – еще одна «серебряная пуля» оказалась, мягко говоря, не из серебра. Но... если мы уже переросли тот уровень, на котором от инструмента почти ничего не зависит (на самом деле это совсем невысокий уровень), то должны искать не серебряную пулю, а адекватный решаемой задаче инструмент. И он, как это ни странно, есть.

Краткий SCM-человеческий словарь

Прежде чем мы перейдем к собственно системе Fossil, давайте ознакомимся с предметной областью Software Configuration Management (SCM) и c принятым в ней языком (потому что после такого знакомства автору статьи будет намного легче – окажется, что о Fossil-то и рассказывать почти нечего).

Мы не будем говорить о SCM формально, в этом нет нужды. Для практикующего программиста, работающего над созданием и сопровождением программного продукта, SCM – это методика и поддерживающий ее инструментарий, обеспечивающие ведение, если так можно выразиться, «истории проекта». Заметьте, что речь идет именно о программном продукте, а не любительской разработке или программе-хобби, создаваемой в неурочное время. Это исключительно важный нюанс – статус программного продукта налагает на его разработчика весьма серьезные обязательства. И именно из-за них история проекта приобретает особую ценность. С разработчиком может случиться всякое, но продукт от этого не изменит своего характера и останется Продуктом. А вот без детального описания истории его создания продолжение работ над ним новыми лицами может вообще стать невозможным (или, обычно, просто становится слишком дорогим удовольствием). Заметьте, что пока мы не делали «нажима» на количество разработчиков, занятых процессом создания и сопровождения программного продукта, что означает – все сказанное выше справедливо и для одного программиста, и для нескольких, и для больших команд.

История создания программного продукта – это, в первую очередь, история создания реализующего его кода, снабженного аннотациями, сопутствующими уточнениями, обсуждениями участников процесса разработки (которые, к слову, могут представлять самостоятельную ценность), ссылками на объясняющие использованные приемы, техники и идеи, ресурсы и т. д. Но все же самая ценная часть истории проекта – код, потому что он в каком-то смысле и есть собственно Продукт. Ценность этой части подтверждается даже тем, что для нее придумана и самостоятельная дисциплина, как бы входящая в SCM – управление версиями ПО, и даже целый класс инструментальных средств.

Что такое код проекта в общем случае – хорошо известно любому программисту: множество файлов исходных текстов, упорядоченных логически и иногда – дополнительно «физически», доступными в системе средствами, например с помощью иерархической структуры, образованной каталогами файловой системы. Подобную иерархию в терминах SCM принято называть исходным деревом (source tree). Проект может состоять из одного исходного дерева или из нескольких. После компиляции и сборки исходных деревьев проекта и получается исполняемая программа, которую в совокупности с множеством факторов мы называем программным продуктом. Исходное дерево называется так не только из-за древовидной структуры, но и потому что оно живое, пока жив программный проект. Это означает, что оно изменяется – в нем появляются новые файлы с исходными текстами, реализующие новую функциональность, удаляются старые фрагменты кода, устраняются ошибки. По сути, в каждый момент времени существования проекта исходное дерево характеризуется некоторым состоянием – его принято называть версией (иногда используется термин baseline, который мы оставим без перевода, достаточно помнить, что это синоним «версии»). Соответственно, история проекта – множество всех версий. Место хранения этого множества принято называть репозиторием. Для физического местонахождения репозитория – компьютера, на котором исполняется система инструментальной поддержки SCM, ничего лучшего, чем «малораспространенное» название «сервер», в лексиконе программных инженеров не отыскалось. Так как SCM-системы всегда создавались с учетом поддержки коллективной работы, непосредственно с сервером разработчики дела не имеют. Каждый из них (также оригинально именуемый «клиентом») обладает собственной копией исходного дерева и локальным репозиторием, которые может изменять. Такую копию принято называть рабочей, или рабочим набором (working copy, working set). Разработчик, даже если он один, всегда работает именно с ней. Иными словами, SCM отводит программисту исключительно один локальный ареал обитания – рабочий набор. Программист может перенести изменения, внесенные в рабочий набор, в репозиторий методом «проталкивания» (push), и напротив, может внести «протолкнутые» кем-то изменения из репозитория в свой рабочий набор – это называется «извлечением» (pull). Одновременное «проталкивание» и «извлечение» – столь часто исполняемая процедура, что ее принято называть «синхронизацией» (sync).

Итак, мы почти добрались до цели – определили базовые понятия SCM-словаря (который мы будем пополнять и уточнять до конца статьи). Но все же требуется еще одно очень важное уточнение. Все указанные ранее понятия были совершенно не связаны с, если так можно выразиться, организационно-территориальной структурой процесса разработки программного продукта. А она может быть разной. Например, централизованной, предусматривающей существование единой для всех разработчиков копии репозитория, а соответственно, и единого сервера. И напротив, она может быть децентрализованной, распределенной. В этом случае единого сервера не существует, соответственно, нет и центрального репозитория, а только рабочие копии разработчиков, которые, по сути, являются полноценными копиями всей истории проекта.

Традиционно различие между централизованной и распределенной моделями делит мир инструментальных средств SCM-систем на два обширных класса. Представителями централизованных (их еще называют клиент-серверными из-за наличия выделенного сервера) систем являются знаменитая CVS (ximbiot.com/cvs/wiki) и популярная Subversion (subversion.tigris.org), наиболее известные из распределенных – Bitkeeper и Git. Предмет нашего обсуждения – Fossil – позволяет формировать не только централизованные и распределенные, но и гибридные структуры, обладающие одновременно свойствами первых и вторых.

Fossil

Начнем мы с решения тривиальной задачи – получения дистрибутива системы. Задача эта тривиальна только на уровне постановки. А вот ее решение требует осознания того факта, что поддержка программного проекта Fossil организована с помощью одноименного инструментального средства. То есть система Fossil разрабатывается с помощью самой себя. Поэтому первое, что нужно сделать, – посетить публичный централизованный сервер проекта и получить доступ к его ресурсам с ограниченными правами анонимного посетителя (fossil-scm.hwaci.com/fossil/login, логин и пароль – anonymous). Метод доступа к серверу, хранящему репозиторий проекта Fossil, подсказывает нам, что система Fossil допускает веб-интерфейс. И это действительно так. Более того, система Fossil не только допускает работу с ней посредством такого интерфейса, она его и реализует, а заодно, при необходимости, реализует и собственный http-сервер.

Итак, мы получили ограниченный доступ к репозиторию Fossil. Для развертывания собственной системы нас интересует ее исходное дерево. В истории проекта, которую тоже можно представить в виде дерева, нас в первую очередь интересуют «листья» (leaves) – самые нижние элементы в иерархии (в IT-индустрии даже деревья растут корнями вверх). Каждый «лист» – это версия, характеризующаяся временем ее возникновения и 40-символьным уникальным идентификатором (UUID, вычисляется с помощью алгоритма SHA1). Самый «свежий лист» – вверху списка версий, он-то нам и нужен. Открыв страницу с ним, мы обнаруживаем идентификатор версии, дату, краткое описание особенностей версии и главное для нас в данный момент – краткий список команд (Commands), инициируемых ссылками веб-интерфейса. Вторая команда – «ZIP Archive» запрашивает у системы формирование архива, содержащего копию исходного дерева в пригодном к сборке продукта формате, а именно, в виде архива с файлами и иерархией объектов файловой системы (каталогов). Активируйте эту ссылку – и получите дистрибутив текущей версии Fossil (на момент написания статьи – версии f7fe15cd0cb6cc28a32cc40c13bb12b9faccd673 от 2007–12–08 03:39:2).

Теперь давайте остановимся на одной только что указанной важной детали – на формате представления репозитория. Его фактически экспорт, выполненный только что по нашей команде «ZIP Archive», свидетельствует в пользу того, что система хранит репозиторий в каком-то ином виде. И это действительно так. Любой репозиторий Fossil на самом деле – один единственный файл, содержащий базу данных СУБД SQLite. Эту весьма специфическую встраиваемую СУБД, поддерживающую подмножество языка SQL, можно смело отнести к классу «самых неизвестных самых популярных программ в мире». Если вы используете браузер Firefox, вы используете SQLite, если вы фотограф и ваш инструмент – Adobe Lightroom, вы используете SQLite, если вы пользователь ОС MacOS X – вы пользователь SQLite, если ваш смартфон работает под управлением ОС Symbian – вы тоже используете SQLite. В рамках этой статьи особенно же важен тот факт, что SQLite и Fossil – проекты в буквальном смысле неразрывные. Fossil основан на SQLite, SQLite разрабатывается с применением Fossil. При этом команда разработчиков SQLite хоть и невелика (в ней всего два человека), но разнесена даже не территориально, а континентально (один разработчик – в США, второй – в Австралии). Впрочем, это все детали – при использовании только Fossil SQLite вы сможете увидеть разве что в исходных текстах системы (исходный C-код СУБД содержится в одном единственном 4-мегабайтовом файле и одном заголовочном файле), но благодаря одному особому свойству SQLite никогда об этой замечательной системе не забудете. А именно, вы в любой момент можете скопировать файл репозитория c вашей x86-машины и «подсунуть» его без изменений Fossil, исполняющейся на машине, архитектура которой отличается другим порядком байтов в слове (например, SPARC, MIPS, ARM), и все будет как надо – SQLite не зависит от низкоуровневых машинных деталей.

Теперь давайте заглянем в полученное в zip-архиве исходное дерево Fossil. Эта программа написана удивительно, если так можно выразиться, «чисто», «незамусоренно» – ни в ее коде нет ничего лишнего, ни в организации дистрибутива. Один каталог с исходными текстами, 60 C-файлов и всего два заголовочных – вот и весь код. В результате трансляции и сборки получается один-единственный исполняемый файл, не требующий каких-то особых процедур инсталляции – просто скопируйте его куда хотите и начинайте пользоваться... встроенной невидимой SQL СУБД, встроенным веб-сервером и механизмами динамической генерации страниц, а также набором команд. Ну а собственно процедура трансляции и сборки для UNIX-совместимых платформ примитивна ввиду строгого соблюдения разработчиками стандартов при кодировании (именно поэтому в проекте Fossil не используют настоящего монстра – autoconfigure), а для пользователей Windows предусмотрена возможность применения разных компиляторов, в том числе и легально бесплатных (единственное «но» – нужна работоспособная утилита make). В общем, чтобы не собрать Fossil – надо постараться.

Продолжение следует

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365