Кошмар слияния платформы объекта

Мы приняли Платформу Объекта, и мы находим, что, когда несколько человек вносят изолированные изменения в своих отдельных ответвлениях управления исходным кодом, существуют крупные конфликты, когда они объединяются в слиянии, приводящем к поврежденным образцовым файлам.

Мы склоняемся в направлении принуждения эксклюзивных выездов на файле, но я хотел бы избежать этого.

Мой вопрос...

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

Поиск чего-то, что доказано, если это возможно.

НОВОЕ ОБНОВЛЕНИЕ: Для тех из Вас, которые сталкиваются с этим вопросом, он основан на старом EF. Я предлагаю переместиться в использование DbContext по EDMX. Существует много информации здесь о ТАК об этом. Простота Базы данных сначала или Кода сначала явно перевешивает утрату разработчика, по-моему.

ОБНОВЛЕНИЕ: Мы решили этот вопрос путем принуждения эксклюзивных изменений в файле. Путем добавления этого процесса мы полностью устранили любые проблемы. В то время как это не было идеальным решением, это было самым надежным и самым легким реализовать.

29
задан Alexandre 30 October 2019 в 06:34
поделиться

0 ответов

Как вы сказали, одним из вариантов является блокировка файла.

Другой возможный вариант - направить все изменения модели через одного человека в команде.

Другой вариант - разбить файл на более мелкие файлы (например, по одному на класс), возможно, оставив позади некоторую поддержку дизайнера.

Другим вариантом является создание собственного процесса, потенциально использующего XSLT для преобразования файла EDMX, но я не уверен, как именно это будет выглядеть, файл designer.cs является огромным трудным для объединения.

Другой вариант - рассмотреть другой ORM.

Я не уверен, что они делают что-то, чтобы улучшить это в следующей версии EF. Сброс такого большого количества данных в один файл не подразумевает масштабируемость любого рода (но LinqToSql делает то же самое - в этом случае Дэмиен Гард создал несколько шаблонов T4, чтобы разбить файл на части, не уверенный, существует ли что-то подобное для EF).

3
ответ дан Michael Maddox 28 November 2019 в 02:05
поделиться

Я не очень знаком с EF, в частности, но у меня было немало проблем с ультра многословным & amp; хрупкий сгенерированный код. В каждом случае лучший ответ о том, как объединить это, было «не надо». В вашем сценарии это, вероятно, означает одно из двух:

1) Уточните модель продвижения кода, чтобы код EF двигался только в одном направлении. Другими словами, каждый конфликт будет разрешен либо как «копия из исходной ветви» (AcceptTheirs), либо как «сохранить цель неизменной» (AcceptYours), и каждый должен знать, что есть что заранее. Чаще всего вам понадобится AcceptTheirs при продвижении недавно протестированного кода в направлении стабильных узлов дерева ветвей и AcceptYours при объединении исправлений обратно в нестабильные ветки / ветки разработки. (Если есть> 1 ветка разработки, вам нужно разделить вещи так, чтобы только код EF, принадлежащий команде, работающей в данной ветке, следовал последнему правилу. Все, что они не изменяют намеренно, должно быть перезаписано кодом других команд вытекает из ветви интеграции, используя AcceptTheirs, если необходимо.)

               /- [...]
               /- v1.1
          /- Release
+ Integration - Dev1 - Dev2 - [...]

" Объединить, скопировать "

2) Буквально не объединять их; полностью исключить код EF из процесса. Когда для интеграции ветвей требуются изменения в базе данных и / или ORM, заново создайте прокси-классы непосредственно из базы данных. (конечно, после разрешения + построения любых конфликтующих изменений в ваших файлах SQL) Экстремальная версия: делайте это при каждой автоматической сборке, а не только при слиянии.

1
ответ дан Markus Jarderot 28 November 2019 в 02:05
поделиться
Другие вопросы по тегам:

Похожие вопросы: