#c# #database #version-control #mercurial
#c# #База данных #управление версиями #mercurial
Вопрос:
Вместо того, чтобы использовать Posts таблицу SQL Server с соответствующей PostRevisions таблицей для управления версиями пользовательского контента в виде плоских файлов (текст / HTML), я бы предпочел, чтобы Mercurial эффективно сохранял изменения для меня и просто отслеживал, где находится файловое хранилище каждого пользователя.
Это действительно упростило бы резервное копирование, в зависимости от того, как вы хотите поделиться содержимым или сегментировать его. Очевидным решением является наличие единого хранилища для хранения всех пользовательских данных с папками для каждого идентификатора пользователя.
Однако у меня плохое предчувствие по поводу проблем с производительностью и параллелизмом при таком подходе при передаче файлов в репозиторий, хранящий миллионы пользовательских файлов.
Кто-нибудь пробовал использовать Mercurial в качестве вторичного хранилища данных для плоских пользовательских файлов?
Комментарии:
1. Какую версию вы пытаетесь изменить? Содержимое системы управления контентом? Возможно, было бы разумнее на самом деле использовать CMS.
2. @Erno, я пытаюсь версифицировать HTML-фрагменты для своих пользователей.
3. Что вы подразумеваете под фрагментами HTML? Действительно, это звучит как работа для CMS. Хранилище стоит недорого, поэтому вам нужно иметь много версий и много пользователей, чтобы предлагаемый вами подход стоил затраченных усилий. У вас есть какие-нибудь цифры?
4. @Erno, никаких цифр. Просто идея. Под HTML-фрагментами я подразумеваю плоский HTML-контент со многими изменениями. Я согласен с «хранилище дешевое», но я не могу игнорировать крутость DSCM :). Что вы подразумеваете под CMS? CMS также должна хранить содержимое, и это либо неверсионные файлы, либо
FileRevisionsтаблица.
Ответ №1:
Если вы не собираетесь воспользоваться преимуществами более мощных функций, предлагаемых SCM-системой, подобной hg, я предлагаю вам не использовать этот подход. Собираетесь ли вы использовать ветви и слияние? Вероятно, нет. Итак, что вы на самом деле получаете, используя hg здесь? Резервное копирование так же просто с помощью базы данных.
В конце концов, СУБД с таблицами записей и ревизий работает просто отлично и является более надежной основой для построения, чем решение, основанное на блокировке файлов (hg, git и т.д.). Вероятно, это тоже работало бы намного лучше.
Кстати, вам также следует оценить хранилища, ориентированные на документы, такие как Mongo или CouchDB.
Комментарии:
1. спасибо за отзыв. Я заинтересован в ветвлении, объединении и эффективном хранении. Изменения, как правило, сильно возрастают, и сохранение всего документа только для последующего сравнения кажется такой пустой тратой времени.
2. Даже если кажется, что hg / git отлично справляются с объединением контента, помните, что вам все равно придется разработать собственную логику разрешения конфликтов и пользовательский интерфейс. Это не так просто. Таким образом, эти функции на самом деле не предоставляются бесплатно. Вам придется проанализировать любой конфликт, посмотрев на diff, а затем определив пользовательский интерфейс разрешения конфликтов для пользователя, который не так пугает, как параллельный инструмент для разделения / слияния.. Я не знаю .. все еще не думаю, что с hg будет меньше работы, чем с DB.
3. Помните также, что SCM-система — это сложная концепция для разработчиков, не говоря уже о пользователях. Вы уверены, что ваше приложение будет достаточно простым способом передавать концепции ветвлений / слияний и конфликтов пользователю? На вашем месте я бы попытался найти готовую библиотеку на стороне клиента, которая решает проблему объединения документов. Для этого не существует 100% серверного решения. Я также не думаю, что хранение всего документа является пустой тратой. Вероятно, вам все равно потребуется кэшировать его для быстрого извлечения, поэтому я бы не стал начинать с оптимизации таким образом.
4. 1 за «все равно придется кэшировать», а хранилище дешевое и «сложное для разработчика, не говоря уже о пользователях». Я согласен с вами. Да, разрешить конфликт непросто. Однако это была идея! Я также читал о проблемах с блокировкой, и лучше использовать базу данных, которая предназначена для обработки этого типа параллелизма.