![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
О системах контроля версий
Sep. 18th, 2015 10:05 amОчень часто мне хочется иметь "контроль версий" для одного файла. Я даже когда-то я даже сделал себе такую систему на коленке хуками в редакторе.
Хуки были следующие:
— при открытии произвольного текстового файла anyname, скрипты создавали (если его ещё не было) каталог anyname~ и в нём файл history и подкаталог archived_versions.
– на сочетание клавишь Ctrl+S я повесил скрипт, который предлагал скинуть текущую версию в архив. Сразу в момент нажатия он аппендил в history строку "Version tagged {Timestamp}-{ContentHash}",
клонировал содержимое редактируемого файла в anyname~/archived_versions/{$USERNAME}/{Timestamp}-{ContentHash}, и предлагал пользователю "short description of changes or version tag", после чего переименовывал файл в {Timestamp}-{ContentHash}-{description/tag}.
– хук, который следил за действиями над текстом в редакторе: при каждом переходе от вводящих текст действий к удаляющим текст действиям, и наоборот, генерился diff относительно предыдущей версии и заносился вместе с таймстемпом и юзернеймом редактирующего в history. Дополнительные диффы заносились по таймеру. Т.е. после каждого сохранения чего-либо в хистори ставился timeout на 5 секунд, если за эти 5 секунд нового diff'а в хистори не появилось, надо проверить изменился ли файл, и, если да, скинуть туда новый diff и снова поставить пятисекундный таймер. Это обеспечивало занесение в файл history действительно истории файла достаточной для любых undo-действий, условие про пять секунд гарантировало гранулярность, условие про фиксацию всех переходов с ввода на удаление, гарантировало что введённый и быстро стёртый текст не пропадёт, даже если ввод-удаление попали в пятисекундное окошко.
Я очень бы хотел, чтобы оно работало так же для нетекстовых файлов: для экселевских таблиц и паўерпойнтовских слайдшоу, для картинок из графического редактора, для всех штук где "self contained project" это не дерево каталогов, а один файл. (Впрочем, ничего не мешает self contained project'у "приветственная картинка" быть частью бОльшего проекта "игра компьютерная Х".)
Я до сих пор считаю, что такой подход к контролю за изменениями в одном файле (возможно, редактируемом несколькими людьми в коллаборативном редакторе вроде google docs, но физически находящимся на одном компьютере) очень близок к оптимуму. Архивирование версий это то, чем должно быть досовское "сохранение файла", а история изменений должна содержать всю undo-history (чтобы ни буква написанного текста/кода, не была удалена безвозвратно) с привязкой к чекпойнтам сохранённых версий. То, что сейчас всякий git хранит историю таких вот "архиваций" файла без привязки к undo history мне неудобно. Впрочем, git это вообще не file level, а folder level VCS, так что это о другом.
Наличие File level versioning как описано выше, очень удобно для работы с файлом в одиночку, либо группой вместе (simultaneously, not concurrently), но совершенно не отменяет потребности в том, чтобы для произведения крупных изменений в файле не мешая другим, нужно бывает этот файл сбренчить, а потом, когда будет готово, мержнуть назад/зафайлить пулл-реквест.
Если б я был султан, я б git расширил: позволил бы навешивать git не только на каталоги (с хранением служебной информации в подкаталоге .git), но и на отдельные файлы (с хранением служебной информации в filename~) и добавил бы туда функционал по треккингу undo-history для поддерживающих это дело редакторов. И добавил бы туда возможность мерджинга ветвей-кузенов при помощи patch reordering, как в darcs camp.
Не могу представить, что бы мне ещё было нужно от системы контроля версий, окромя, конечно, идеального визуального интерфейса, и высокой скорости работы с проектами любого размера.
Хуки были следующие:
— при открытии произвольного текстового файла anyname, скрипты создавали (если его ещё не было) каталог anyname~ и в нём файл history и подкаталог archived_versions.
– на сочетание клавишь Ctrl+S я повесил скрипт, который предлагал скинуть текущую версию в архив. Сразу в момент нажатия он аппендил в history строку "Version tagged {Timestamp}-{ContentHash}",
клонировал содержимое редактируемого файла в anyname~/archived_versions/{$USERNAME}/{Timestamp}-{ContentHash}, и предлагал пользователю "short description of changes or version tag", после чего переименовывал файл в {Timestamp}-{ContentHash}-{description/tag}.
– хук, который следил за действиями над текстом в редакторе: при каждом переходе от вводящих текст действий к удаляющим текст действиям, и наоборот, генерился diff относительно предыдущей версии и заносился вместе с таймстемпом и юзернеймом редактирующего в history. Дополнительные диффы заносились по таймеру. Т.е. после каждого сохранения чего-либо в хистори ставился timeout на 5 секунд, если за эти 5 секунд нового diff'а в хистори не появилось, надо проверить изменился ли файл, и, если да, скинуть туда новый diff и снова поставить пятисекундный таймер. Это обеспечивало занесение в файл history действительно истории файла достаточной для любых undo-действий, условие про пять секунд гарантировало гранулярность, условие про фиксацию всех переходов с ввода на удаление, гарантировало что введённый и быстро стёртый текст не пропадёт, даже если ввод-удаление попали в пятисекундное окошко.
Я очень бы хотел, чтобы оно работало так же для нетекстовых файлов: для экселевских таблиц и паўерпойнтовских слайдшоу, для картинок из графического редактора, для всех штук где "self contained project" это не дерево каталогов, а один файл. (Впрочем, ничего не мешает self contained project'у "приветственная картинка" быть частью бОльшего проекта "игра компьютерная Х".)
Я до сих пор считаю, что такой подход к контролю за изменениями в одном файле (возможно, редактируемом несколькими людьми в коллаборативном редакторе вроде google docs, но физически находящимся на одном компьютере) очень близок к оптимуму. Архивирование версий это то, чем должно быть досовское "сохранение файла", а история изменений должна содержать всю undo-history (чтобы ни буква написанного текста/кода, не была удалена безвозвратно) с привязкой к чекпойнтам сохранённых версий. То, что сейчас всякий git хранит историю таких вот "архиваций" файла без привязки к undo history мне неудобно. Впрочем, git это вообще не file level, а folder level VCS, так что это о другом.
Наличие File level versioning как описано выше, очень удобно для работы с файлом в одиночку, либо группой вместе (simultaneously, not concurrently), но совершенно не отменяет потребности в том, чтобы для произведения крупных изменений в файле не мешая другим, нужно бывает этот файл сбренчить, а потом, когда будет готово, мержнуть назад/зафайлить пулл-реквест.
Если б я был султан, я б git расширил: позволил бы навешивать git не только на каталоги (с хранением служебной информации в подкаталоге .git), но и на отдельные файлы (с хранением служебной информации в filename~) и добавил бы туда функционал по треккингу undo-history для поддерживающих это дело редакторов. И добавил бы туда возможность мерджинга ветвей-кузенов при помощи patch reordering, как в darcs camp.
Не могу представить, что бы мне ещё было нужно от системы контроля версий, окромя, конечно, идеального визуального интерфейса, и высокой скорости работы с проектами любого размера.
