From 3386905076e04940717c6c5ff23bdcbda6178b70 Mon Sep 17 00:00:00 2001
From: Sergey Matveev <stargrave@stargrave.org>
Date: Sat, 19 Feb 2022 12:49:04 +0300
Subject: [PATCH] =?utf8?q?=D0=A0=D0=B5=D0=B0=D0=BB=D0=B8=D0=B7=D0=B0=D1=86?=
 =?utf8?q?=D0=B8=D0=B8=20redo?=
MIME-Version: 1.0
Content-Type: text/plain; charset=utf8
Content-Transfer-Encoding: 8bit

Готовлюсь тут друзьям программистам рассказать про redo. И надо же
сделать небольшое резюме по имеющимся реализациям. Если кратко и с ходу
по памяти, то всё не очень, но оно исправимо:

apenwarr/redo (https://redo.readthedocs.io/en/latest/) -- по сути
единственный недостаток это то, что он на Python. Значит даже просто его
запуск будет на глаз заметен. Он не делает автоматическое хэширование
целей, а полагается на mtime+inodeNum+size+мелочи, что означает
возможные false positive, но это терпимо. Главное чтобы было собрано то,
что должно собраться. Есть особенность неприятная в виде SQLite3 БД,
которая создаётся один раз на проект и важно чтобы это было в его
top-директории. Сам автор признаёт что корректнее бы было делать .redo в
каждой поддиректории. Не помню уважает ли он umask. Не делает fsync-и
даже для SQLite3. Но жить с этим можно. Ценнейшая вещь в этом проекте
это документация, которую стоит читать всем кто погружается в redo!

https://github.com/leahneukirchen/redo-c -- 1kLOC Си без зависимостей,
вместе с встроенной SHA256 реализацией. Умеет распалаллеливаться. umask
не уважает. Всю метаинформацию размещает рядом с целями, вместо
помещения в отдельную директорию. Всё это я даже исправлял в своём fork.
И всё бы ничего (с этими правками), если бы не один коммит на пару
строчек, который создаёт результирующий файл при пустом stdout. Это
полностью уничтожает возможность создания виртуальных OOD-целей.
Буквально если сделать revert этих пары строчек -- redo-c бы был
полностью юзабельной отличной реализацией, смотрящей на ctime+hash.

https://github.com/gotroyb127/baredo -- совсем новый проект, который я,
так сказать, консультировал и из-за меня появились fsync-и честные,
umask-дружелюбность, атомарное обновление файлов с метаинформацией и
возможность их чтения человеком, плюс распараллеливание задач (правда
сейчас автор там что-то ещё коммитит и я не знаю работает ли оно), плюс
то, что должно учитываться содержимое файла, как будто он был open/read,
а изначально там содержимое самой символической ссылки например
читалось. Но автор ни в какую не соглашается использовать что-либо кроме
mtime. Ни apenwarr статьи, ни мои аргументы его ни в чём не убеждают.
Если я сделаю truncate -r 1 2 ; touch -r 1 2 ; mv 2 1, то его baredo не
увидит изменений. apenwarr разумно учитывается inode number поэтому и у
него таких проблем не будет. Но если в baredo в коде поменять "mtime" на
"ctime", то всё будет вполне себе хорошо.

http://www.goredo.cypherpunks.ru/ -- насколько понимаю, сейчас это
основная рекомендуемая большинством реализация. Самая навороченная в
плане дружелюбности к разработчику (все фичи apenwarr заюзал, плюс свои
накрутил). Самая замороченная на fsync-ах и атомарности. Замороченная на
(не)доверии к файловым системам, позволяя на выбора даже не учитывать
ctime или например наоборот доверять mtime. umask дружелюбна. Jobserver
совместим с GNU Make и NetBSD bmake (apenwarr единственный кто совместим
хотя бы только с GNU). Покрыта интеграционными тестами, на некоторых из
которых вроде бы apenwarr бы уже не проходил.

apenwarr/do -- входит в apenwarr/redo и это мизерная POSIX shell
реализация пригодная только для сборки с нуля, без распараллеливания и
учёта зависимостей. Пригодна для подкладывания в tarball-ы софта чтобы
его можно было собрать без дополнительных зависимостей. Под OpenBSD, как
недавно выяснил, оно не работает правда (зато goredo собирается и
работает).

redo-sh (http://news.dieweltistgarnichtso.net/bin/redo-sh.html) -- из
неё я взял основную массу интеграционных тестов (другую часть тестов из
apenwarr/redo). Использовать не пробовал, так как оно требует GNU
утилиты и под BSD работать не будет.
-- 
2.52.0