Как реализовать кастомную систему контроля версий комментариев на JS/TS?
Делаю проект на node.js, express.js, react.js.
Необходимо реализовать кастомную систему контроля версий комментариев пользователей на JS/TS, чтобы можно было отслеживать все изменения их комментариев, чтобы это всё в последствии отнимало как можно меньше памяти.
Можете примерно объяснить логику как это сделать? И в каком направлении думать?
partyzanx, а почему тогда нет тега svn, perforce, plastic?
Теги не так работают. Да и не надо вам тут ничего из того что умеет гит по сути. Совершенно другие единицы атомарности.
Комментарии так часто исправляют, что потребовалась система анализа этих изменений?
Если же речь про расход памяти. то это уже не про контроль версий, а про систему хранения комментариев.
Определитесь, что именно вам нужно? Компактное хранение или контроль версий?
И вы не поверите, но гит в каждом коммите изначально записывает полную версию каждого измененного файла. Уже потом, в фоновом режиме оптимизирует своё внутреннее хранилище объектов.
Комментарии так часто исправляют, что потребовалась система анализа этих изменений?
Да
гит в каждом коммите изначально записывает полную версию каждого измененного файла. Уже потом, в фоновом режиме оптимизирует своё внутреннее хранилище объектов.
Как он выявляет разницу с предыдущим коммитом? Хотелось бы этот же механизм понять и накастылить на JS / TS
Когда пользователь изменяет комментарий, то создается новая версия этого комментария.
В БД лучше сделать дополнительный столбец, указывающий на ID нового комментария: когда происходит изменение, то обновляешь этот столбец - указываешь ID новой версии.
История получается линейной, чтобы восстановить историю - находишь последний без установленного этого ID
partyzanx, ну иначе можно сделать так:
1. Каждый раз вычислять дельту изменений с предыдущим комментарием (+CPU время)
2. Добавить столбец по типу "History", который будет хранить массив этих изменений (+Место)
3. Чтобы получить актуальное состояние:
- Либо берем исходное сообщение и применяем дельты
- Либо сразу храним обновленное состояние
Сергей Соловьев, если смотреть как работают коммиты в Гите, то он как-то отслеживает в какой строке в символах под каким номером были изменения, потом это всё как-то по-умному записывает очень короткой записью что было изменено, где было изменено, на сколько подвинулся/сместился текст с места изменения. И когда мы хотим посмотреть какой-то коммит, то Гит перебирает все предыдущие коммиты и смотрит изменения рекурсивно.
partyzanx, на сколько мне известно, гит не смотрит на содержимое строк (сами символы) - он подсчитывает хэш строки, и так определяет какая строка добавилась, какая изменилась или удалилась.
Короче, он сохраняет целые строки, а не символы.
partyzanx, БД занимает ровно столько, как вы ее настроите.
Ну и в принципе. не делайте тогда ничего, ибо чтобы вы не сделали - все будет занимать память.
partyzanx, А есть данные как часто юзеры меняют комментарии? По моему не так часто, чтобы отношение памати на дополнительные версии к памяти на комментарии было сколько либо значимым, но это лишь гипотеза.
вариант на тему - можно оборачивать изменения комментария в тег с версией комментария и действием. К примеру при удалении строки не фактически удаляешь ее из текста, а оборачиваешь в условный тег commentDaletePart v=2.Далее при запросе комментария парсишь только последнюю версию. Это так, фантазии на тему танцев с бубнами.
Kentavr16, да так можно, только вопрос как это отследить)))
Была идея отслеживать через браузерные события, типа где-то ставишь курсор, там появляется инпут, вводишь данные, хотя для пользователя это незаметно, он будет думать, что продолжает писать в общем поле)
partyzanx, но всегда нужно держать в уме что единственный нормальный вариант уже предложен в ответе. Жалеть пространство на хранение старых версий текста это странно. И после всех изменений это будет точно не про оптимизацию
