Что: 3386905076e04940717c6c5ff23bdcbda6178b70
Когда: 2022-02-19 12:49:04+03:00
Темы: redo
Реализации redo Готовлюсь тут друзьям программистам рассказать про 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 работать не будет.
Сгенерирован: SGBlog 0.34.0