Написание собственной программы контроля версий файлов

Question

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

Какие проблемы необходимо учитывать, чтобы написать простую систему управления версиями файлов? (Каковы минимально необходимые функции?)

Это выполнимая задача для одного человека?

Answer 1

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

Еще один хороший пример - серия статей Source Control HOWTO . Да, это все о том, как использовать управление исходным кодом, но в нем много информации о решениях и компромиссах, которые разработчики должны принять при проектировании системы. Лучшим примером этого является, вероятно, его статья о Repositories , где он объясняет различные методы хранения версий. Я действительно многому научился из этой серии.

Answer 2

Насколько просто?

Можно написать систему контроля версий с помощью однострочного сценария оболочки upversion.sh:

cp $WORKING_COPY $REPO/$(date +"%s")

Для больших бинарных активов это все, что вам нужно! Его можно легко улучшить, например, сделав папки версий доступными только для чтения, возможно, записав метаданные для каждой версии (например, вы можете получить текстовый файл на $REPO/$(date...).meta)

Это звучит как огромное упрощение, но это не далеко от систем управления активами, которые используют многие кинокомплексы (например)

Вы действительно должны знать, что вы хотите версии и почему ..

При использовании больших двоичных ресурсов (скажем, видео) вам необходимо сосредоточиться на инструментах для визуального сравнения версий. Вы также, вероятно, должны иметь дело с зависимостями («Мне нужны image123.jpg и video321.avi для создания этого изображения»)

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

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

Нет идеального способа для версионирования всего, вы должны сосредоточиться на том, чтобы хорошо выполнять одну вещь. Git отлично подходит для текста, но не для двоичных файлов. Adobe Version Cue отлично работает с двоичными файлами (изображениями), но бесполезна для текста.

Полагаю, что вещи для рассмотрения можно суммировать как ..

• Что вы хотите версии?
• Почему я не могу использовать (или расширять / модифицировать) существующую систему?
• Как я буду отслеживать различия между версиями? (целые файлы? deltas?)
• Какие еще данные мне нужно приложить к версиям? (Автор? Метка времени? Зависимости?)
• Какие задачи обычно приходится выполнять пользователю (разбор? Возврат определенных файлов?)

Answer 3

Загляните в вопрос " основные понятия " о (D) VCS.
Короче говоря, написание VCS потребовало бы принятия решения по каждому из этих основных понятий (центральный или распределенный, линейный или DAG, файловый или репозиторий-ориентированный, ...)

Я считаю, что это не "быстрый" проект;)

Answer 4

Если вы Линус Торвальдс, вы можете написать что-то вроде Git за месяц.

Но «система контроля версий» - это настолько расплывчатая и растягиваемая концепция, что ваш вопрос действительно не поддается ответу.

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

Answer 5

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

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

Answer 6

Что может дать вам хороший обзор в менее технической форме: Притча о Git Это хорошая абстракция на принципах git, но она дает очень хорошее понимание того, что VCS должна уметь выполнять. Все, что за этим стоит, является скорее «низкоуровневым» решением.

Answer 7

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

Answer 8

Хороший дельта-алгоритм, хорошее сжатие и эффективность сети.

Answer 9

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

Answer 10

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

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