Управление файлами конструктора баз данных Visual Studio в системе управления версиями - PullRequest
1 голос
/ 19 мая 2011

Я работаю над проектом, в котором для создания слоя доступа к данным используется графический дизайнер Visual Studio.

Я использую Mercurial в качестве моей VCS, но это не должно иметь большого значения. Всякий раз, когда я изменяю экран конструктора БД в одной ветви, затем меняю другую в другой ветви и пытаюсь объединить две ветви ... Я почти всегда получаю ужасно сложные конфликты слияния, которые трудно понять даже вручную. Файлы .cs, которые создает дизайнер БД.

Как вы справляетесь с этим?

Ответы [ 2 ]

1 голос
/ 19 мая 2011

Я думаю, что ответ @Doc Brown отличный, и это общая проблема с DVCSs

Учитывая рабочий процесс копирования-изменения-слияния DVCS, вам лучше использовать текстовый формат (как указано в @Doc Brown) или разработать процесс / соглашение, позволяющее сообщать об изменениях остальной части вашего команда, чтобы вы не наступали друг на друга при попытке обновить / вытащить.

Возможность обработки двоичных файлов хорошо работает с централизованным VCS, поскольку у вас есть (иногда ограниченная) возможность заблокировать файл при извлечении (рабочий процесс Checkout-Modify-Checkin).

FWIW, вот отличная дискуссия на тему SO.

Двоичные файлы в DVCS

1 голос
/ 19 мая 2011

Различия в ветвлении / слиянии БД не очень хорошо работают с текстовыми инструментами сравнения / слияния. Есть специальные инструменты, такие как ERwin (см. http://erwin.com/),, которые могут справиться с этим, но эти инструменты дороги и, вероятно, их будет непросто интегрировать в вашу VCS.

Я думаю, что лучший вариант при использовании конструктора БД Visual Studio - полностью избежать ветвления. Или не проектируйте свою БД, используя конструктор БД. Лучше иметь более или менее простой файл описания для вашей БД и сгенерировать все остальное, что вам нужно, с помощью рукописного генератора.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...