Есть, кажется, множество систем управления версиями. Поэтому, чтобы сделать плохой вывод, его должно быть легко написать.
Каковы некоторые проблемы, которые необходимо учитывать, чтобы написать простую систему управления версиями файлов? (Каковы минимально необходимые функции?)
Является ли это выполнимой задачей для одного человека?
Хорошим местом для изучения контроля версий является Eric Sink Weblog. Его последняя статья Временные и космические компромиссы в хранилище контроля версий, например.
Другим хорошим примером является его серия статей Source HOWTO. Да, это все о том, как использовать контроль источника, но в нем есть много информации о решениях и компромиссах, которые разработчики должны делать при разработке системы. Лучшим примером этого является, вероятно, его статья о Repositories, где он объясняет разные способы хранения версий. Я действительно многому научился из этой серии.
Насколько прост?
Возможно, вы можете написать систему управления версиями с однострочной оболочкой script, upversion.sh:
cp $WORKING_COPY $REPO/$(date +"%s")
Для больших двоичных активов это в основном все, что вам нужно! Это можно было бы легко улучшить, скажем, сделав папки версий доступными только для чтения, возможно, записывая метаданные с каждой версией (например, текстовый файл может быть $REPO/$(date...).meta)
Это звучит как огромное упрощение, но это недалеко от систем управления активами, которые используют многие кинопостановки (например)
Вам действительно нужно знать, что вы хотите изменить, и почему..
При использовании больших двоичных активов (например, видео) вам нужно сосредоточиться на инструментах для визуального сравнения версий. Вам также, вероятно, нужно иметь дело с зависимостями ( "Мне нужны изображения123.jpg и video321.avi для создания этого изображения" )
С кодом вам нужно сосредоточиться на таких вещах, как простое различие между любыми двумя версиями. Кроме того, поскольку редактирование исходного кода обычно невелико (несколько символов из проекта со многими тысячами строк), было бы ужасно неэффективно копировать весь проект для каждой версии, поэтому вы сохраняете различия между каждой версией (дельта-кодирование).
Для версии базы данных вы, вероятно, хотите хранить информацию о схеме, отслеживать новые таблицы или столбцы или корректировки существующих (а не вычислять дельта файлов базы данных или делать копии, подобные предыдущим двум системам)
Нет идеального способа для версии, вы должны сосредоточиться на том, чтобы делать что-то хорошо. Git отлично подходит для текста, но не для двоичных файлов. Adobe Version Cue отлично сочетается с бинарными файлами (изображениями), но бесполезно для текста.
Я предполагаю, что рассматриваемые вещи можно суммировать как...
Посмотрите на вопрос " основные понятия" о (D) VCS.
Короче говоря, написание VCS будет включать принятие решений относительно каждой из этих основных концепций (Central vs. Distributed, linear vs. DAG, ориентированный на файл и центр репозитория,...)
Я считаю, что это не "быстрый" проект;)
Если вы Линус Торвальдс, вы можете написать что-то вроде Git через месяц.
Но "система контроля версий" - такая неопределенная и растяжимая концепция, что ваш вопрос действительно неопровержимый.
Я хотел бы спросить себя, чего вы хотите достичь (узнайте о VCS, изучите язык,...), а затем определите четкую цель. Хорошо иметь проект, но также хорошо иметь достижимую цель за небольшой промежуток времени. Небольшие успехи хороши для вашего морального духа.
Это действительно плохой вывод. Мое личное мнение здесь заключается в том, что проблемная область настолько широка и в целом сложна, что никто не стал ее "правильным", тем не менее, люди пытаются решить его снова и снова, с разных точек зрения и при разных допущениях. Это, конечно, не означает, что вы не должны пытаться. Просто имейте в виду, что перед вами было много умных людей, поэтому вы должны сделать домашнее задание.
Простой один может сделать один человек для возможности обучения. Одна из проблем, которую вы могли бы рассмотреть, - это эффективное хранение дельтах текста. Очень популярным дельта-форматом является один из RCS (используется многими программами управления версиями). Вы можете изучить его, чтобы получить идеи.
Что может дать вам хороший обзор менее техничным образом: Git Притча. Это хорошая абстракция на принципах git, но она дает очень хорошее представление о том, что VCS должен выполнять. Все это выходит за рамки довольно "низкоуровневых" решений.
Хороший алгоритм дельта, хорошее сжатие и эффективность сети.
Чтобы написать доказательство концепции, вы, вероятно, могли бы это сделать, внедрить или заимствовать инструменты, о которых говорит Алан.
IMHO, наиболее важным аспектом VCS является простота использования. Это звучит как странное утверждение, но, когда вы думаете об этом, пространство на жестком диске является одним из самых простых ИТ-товаров для масштабирования по горизонтали, поэтому плохое сжатие или даже настоящие неряшливые дельта будут допущены. Основная причина, по которой люди требуют улучшения в системах управления версиями, - это делать более общие интуитивные задачи или поддерживать дополнительные функции, которые в конечном итоге требуют люди, но которые не были очевидны перед выпуском. И поскольку инструменты управления версиями, как правило, монолитные и тщательно интегрированы в компанию, стоимость переключения высока, и может оказаться невозможной поддержка новой функции без нарушения существующего репо.
Очень минимальным необходимым условием является исчерпывающий и точный набор тестов. Никто (включая вас) не захочет использовать вашу новую систему, если вы не сможете продемонстрировать, что она работает, надежно и полностью безошибочно.