Один объект, несколько ревизий
Представим цифровой проект, который развивается последовательно. В R1 появляется исходное состояние и первый фиксированный результат. В R2 меняется редактируемая часть и формируется новый результат. В R3 работа продолжается ещё раз. Для человека это один проект, но для проверки — три самостоятельных набора с разным содержимым, контрольными суммами и временем фиксации.
Удобно хранить общий идентификатор логического объекта и отдельные идентификаторы ревизий. Тогда история показывает связь состояний, но не стирает их границы. Parent link может указывать, что R2 продолжает R1, а R3 продолжает R2. Такая связь объясняет последовательность, однако не разрешает брать произвольные компоненты у родителя или потомка.
В публичном релизном контуре Recoverable готовые ревизии описаны как immutable: для каждой доступны собственные EOC, manifest и SHA-256, а готовое состояние не изменяется через операции обновления. Новое изменение создаёт новую ревизию. Фактические операции и ограничения собраны в разделе для разработчиков.
Как возникает смешение
Смешение ревизий часто не похоже на повреждение. Файл из R2 и файл из R3 могут быть полностью целыми, открываться и проходить собственную проверку SHA-256. Ошибка состоит в том, что вместе они не образуют ни R2, ни R3. Например, фиксированное представление показывает результат второго этапа, а редактируемое состояние уже содержит изменения третьего. Пользователь видит одну картину, но продолжает работу с другой.
Имена и даты не дают надёжной защиты. Файлы можно переименовать, системное время — изменить, а копирование — выполнить в произвольном порядке. Даже одинаковая структура каталогов не доказывает, что содержимое относится к одной версии. Нужна явная связь каждого обязательного компонента с идентификатором ревизии и ожидаемыми контрольными значениями.
Что происходит перед restore
Сначала система получает идентификатор логического объекта и целевую ревизию, например R2. Затем manifest задаёт ожидаемые роли и компоненты этого состояния. Для найденных файлов пересчитываются контрольные суммы. После локальной проверки система подтверждает, что descriptors относятся к R2 и согласованы между собой. Только затем формируется решение, разрешающее или блокирующее восстановление.
Если отсутствует обязательный компонент, результат не следует дополнять файлом из R1 или R3 автоматически. Такой «ремонт» скрывает потерю и создаёт состояние, которого никогда не было в истории. Корректнее остановить процесс, сообщить о неполном составе и дать оператору выбрать другой целый набор либо восстановить недостающий артефакт из подтверждённой копии.
Если SHA-256 не совпал, причина также должна быть видимой: проверяемые байты отличаются от ожидаемых. Система не обязана угадывать, произошло ли случайное повреждение или намеренная замена, чтобы безопасно заблокировать restore. Дополнительный аудит и контекст доступа помогают расследовать событие, но базовое решение опирается на проверяемое несоответствие.
Зачем хранить историю неизменяемой
Если R1 можно незаметно переписать после создания R2, идентификатор перестаёт обозначать стабильное состояние. Старый отчёт и сохранённая контрольная сумма начинают относиться к данным, которых больше нет. Неизменяемость готовой ревизии сохраняет смысл ссылок, сравнений и повторной проверки. Исправление оформляется как новая ревизия, а прежняя остаётся частью истории.
Это не означает, что любой черновик должен навсегда занимать место. Политика хранения и удаление логического объекта — отдельные управляемые операции. Важно другое: пока ревизия объявлена существующей и готовой, её содержимое не меняется под прежним номером. Публичная архитектурная модель показывает lifecycle от создания версии до проверки и решения о восстановлении.
Пример выбора между R1, R2 и R3
Допустим, R3 — последняя версия, но её редактируемый компонент не прошёл проверку. Автоматически подставить ED из R2 нельзя: получится гибрид. Возможны два честных решения. Первое — заблокировать R3 и восстановить целиком проверенную R2, явно сообщив пользователю, что выбрана предыдущая ревизия. Второе — получить корректную копию недостающего компонента R3 и повторить проверку. В обоих случаях цель восстановления остаётся однозначной.
- R1, R2 и R3 имеют отдельный manifest и отдельные ожидаемые хеши.
- Каждый компонент проверяется в контексте выбранной ревизии.
- Parent link описывает историю, но не разрешает смешение.
- Ошибка блокирует restore до явного безопасного решения.
- Отчёт называет выбранную ревизию и обнаруженные несоответствия.
Контейнерная модель Recoverable EOC связывает фиксированное представление, редактируемое состояние и данные ревизии. Благодаря этому «восстановить R2» означает получить проверенный набор R2, а не собрать приблизительно подходящие файлы из всей истории.
Практический вывод
Версия полезна, когда является проверяемой границей. Номер без manifest, хешей и правил неизменяемости остаётся лишь подписью на папке. Связанная ревизия позволяет воспроизводимо выбрать цель, проверить её и объяснить, почему восстановление разрешено либо остановлено. Именно это защищает рабочий процесс от тихого перехода к смешанному состоянию.