Безопасно ли фиксировать больше файлов в качестве ловушки перед фиксацией?

Question

Я хочу автоматически фиксировать базу данных, когда мы копируем файлы из одной ветви в другую в Subversion. Безопасно ли использовать svn commmit как часть ловушки перед фиксацией, предполагая, что мы делаем это в очень специфических случаях?

Answer 1

Даже если это безопасно, оно, вероятно, не даст ожидаемого эффекта.

Когда вы выполняете предварительную фиксацию, новая транзакция уже создана, но не зафиксирована. У вас есть доступ к этой информации для выполнения вашей работы, но дополнительный svn commit создаст отдельную транзакцию, которая также еще не совершена.

Эта новая транзакция не увидит никаких изменений в вашей текущей транзакции, потому что она еще не завершена.

Вы, вероятно, хотите, чтобы некоторые пользовательские скрипты, которые вы запускаете, делали это для вас, возможно, часть вашей системы сборки.

Кроме того, вам нужна рабочая копия для фиксации, у вас нет той, где запускается хук pre-commit на сервере. Возможно, вам удастся что-то сделать вместе с общей рабочей копией и надеяться, что два человека не вызовут одновременное выполнение хука pre-commit, но, опять же, вам, вероятно, лучше использовать специальное решение для сценариев.

Answer 2

Сам коммит в SVN безопасен. В случае, если ваша версия устарела, когда вы делаете коммит, операция будет отклонена. Конечно, фиксация двоичного файла в SVN делает невозможным какое-либо разрешение конфликтов на основе SVN, что печально ...

Что вам следует беспокоиться, так это svn update. Вы сказали, что хотите хранить базу данных в SVN. Насколько мне известно, ни MySQL, ни Oracle, ни MS-SQL не нравится, когда пользователь играет со своими файлами данных ... Это можно сделать, но файл конфигурации базы данных также должен храниться в SVN. И, возможно, журналы тоже. И, конечно же, СУБД не должна работать при обновлении. Довольно много шума, не правда ли?

Вы также можете заблокировать файлы с помощью команды SVN, чтобы запретить изменение другим пользователем.

Учитывая все это - может быть, есть другое, более подходящее для вас решение, чем хранение двоичного файла базы данных в текстовой системе контроля версий?

Answer 3

Даже если это безопасно, это звучит как что-то, что может сбить с толку ваших пользователей. Они попросили, чтобы Х был предан, а Х + Y предан. Это рецепт для людей, которые понятия не имеют, что происходит. Особенно, когда вы пытаетесь добавить новых членов команды.

Я также хотел бы отметить, что, даже если это работает нормально, для меня это звучит как граничное условие для работы VCS. И за эти годы я научился не слишком сильно толкать свои инструменты к краям без чертовски веских причин. В пограничных условиях возникают ошибки, и я опасаюсь, что что-то может измениться в будущем.

Answer 4

Это звучит как сомнительное предложение - независимо от того, какую VCS (систему контроля версий) вы используете. Как всегда, подробно, «это зависит».

Первая проблема: «что значит« зафиксировать базу данных »»? Предположительно, вы думаете с точки зрения базы данных, хранящейся в одном файле, и вы бы сделали простую фиксацию файла в виде двоичного фрагмента данных. Это предполагает, что никто другой не использует базу данных. Основные СУБД предоставляют инструменты для обеспечения согласованного резервного копирования базы данных, даже если она используется в данный момент. Если в вашей СУБД запущен сервер, это может стать довольно неприятным, если у вас незаметно есть VCS, выполняющая регистрацию. Типичная VCS удалит извлеченный в данный момент файл и заменит его новой версией (например, в случае, если в нем есть ключевые слова, которые необходимо развернуть). Вы должны убедиться, что ключевые слова не раскрываются в файле СУБД. Что происходит, когда база данных увеличивается и занимает более одного пространства?

Я был бы более склонен обеспечить резервное копирование базы данных, а затем контролировать ее версию. Но это во многом зависит от того, что ваша СУБД предоставляет в качестве средств резервного копирования (и средств восстановления - я предполагаю, что целью является восстановление базы данных в случае необходимости).

Наконец, для большинства систем содержимое базы данных не особенно важно; что имеет решающее значение, как правило, это схема данных - таблицы, столбцы, индексы, ограничения, хранимые процедуры, представления, разрешения, ... Фактические строки данных обычно имеют минимальное значение.