Исправление qnikst, (текущая версия) :
странно, я сразу так и понял
~/bin/prog <- shell скрипт, который делает всё что надо
/usr/bin/prog <- сама прога
скрипт - синхронизует текущий профиль с тем, что в облаке, вызывая progdiff если придётся, и запускает программу, после завершения снова синхронизирует (pull -> решение конфликтов -> push).
с этим подходом не нужно думать о запрете запуска. Так же в случае если аналогичный подход нужен в рамках одного хоста, то можно ввести доп уровнь - tmpfs (который ты и так хочешь), а именно после первой синхронизации профиля класть его в tmpfs, и после завершеиня мержить tmp профиль с основным на хосте (просто pull -> решение конфликтов), потом синхронизировать с облаком..
поверх существующей VCS это хорошо ляжет.
Исправление qnikst, :
странно, я сразу так и понял
~/bin/prog <- shell скрипт, который делает всё что надо
/usr/bin/prog <- сама прога
скрипт - синхронизует текущий профиль с тем, что в облаке, вызывая progdiff если придётся, и запускает программу, после завершения снова синхронизирует (pull -> решение конфликтов -> push).
с этим подходом не нужно думать о запрете. Так же в случае если аналогичный подход нужен в рамках одного хоста, то можно после первой синхронизации профиля класть его в tmpfs, и потом сначала мержить у себя, потом синхронизировать с облаком..
поверх существующей VCS это хорошо ляжет.
Исходная версия qnikst, :
странно, я сразу так и понял
~/bin/prog <- shell скрипт, который делает всё что надо
/usr/bin/prog <- сама прога
скрипт - синхронизует текущий профиль с тем, что в облаке, вызывая diff если придётся, и запускает программу, после завершения снова синхронизирует (pull -> решение конфликтов -> push).
с этим подходом не нужно думать о запрете. Так же в случае если аналогичный подход нужен в рамках одного хоста, то можно после первой синхронизации профиля класть его в tmpfs, и потом сначала мержить у себя, потом синхронизировать с облаком..