Да, последовательность ревизий равна аналогично ориентированному ациклическому графу.Я обсуждал это (на концептуальном уровне) в Репликация CouchDB похожа на Git .
Мне нравится говорить, что CouchDB похож на Git в педагогических целях.Однако есть существенные различия.Вот несколько примеров:
- CouchDB не хранит старые данные , только старые идентификаторы ревизий
- CouchDB в конечном итоге усекает очень длинные истории ревизий, чтобы сохранить производительность
Таким образом, я не уверен, что вы сможете добиться трехстороннего слияния на практике, потому что самое большее у вас будет только две ревизии данных для работы: источник и цель.Будет известно, что общий предок существует, но его значение не будет.
Хотя это может быть проблемой в целом , существует несколько «читов», которые делают его не таким уж плохим на практике.
- Функция
validate_doc_update() предотвращает произвольные изменения.Это может даже потребовать изменения метаданных, которые будут сохранены как часть документа.(Но это решение на уровне приложений.) - Большой класс данных для большого класса приложений может быть объединен в двух направлениях: например, выберите последнюю метку времени;объединить разные телефонные номера в массив телефонных номеров;и т. д.
Очевидно, что они сильно зависят от приложения и не являются общими решениями.