Запись моей собственной программы управления версиями файла

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

Не «быстрый» проект, я верю;)

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

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

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

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

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

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

Вы могли бы, возможно, написать систему управления версиями с однострочным сценарием оболочки, upversion.sh:[12107 impression Для больших двоичных ресурсов это практически все, что вам нужно! Его можно довольно легко улучшить, например, сделав папки версий доступными только для чтения, возможно, записав метаданные для каждой версии (у вас может быть текстовый файл по адресу $ REPO / $ (date ...). Meta для пример)

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

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

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

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

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

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

Я полагаю, что все, что нужно учесть, можно резюмировать как ..

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

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

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

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

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

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

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

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

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