Регистрация в Designer Сгенерированный код в TFS, проблемы

Question

Я только что разговаривал с моим менеджером по поводу политик регистрации в проекте, над которым я сейчас работаю. По сути, я пытался отредактировать файл, который уже был извлечен другим разработчиком, и я не смог - я спросил своего менеджера, почему мы не можем редактировать один и тот же класс одновременно, и он объяснил причину отключения этой функции: У нас было много проблем с разработчиками, которые редактировали одну и ту же форму (или что-то визуальное в дизайнере), а затем проверяли ее. Слияние изменений в сгенерированном дизайнером коде было большой проблемой ...

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

Кто-нибудь из вас сталкивался с проблемами при редактировании той же Формы (или чего-либо в конструкторе), что и у другого разработчика, и последующей проверкой TFS? Если да, то как ваша команда справилась с этой проблемой? Вы также отключили возможность для разработчиков работать в одном классе?

РЕДАКТИРОВАТЬ: Следующий пост ( найден здесь ) является именно той проблемой, которую описывал мой менеджер. Кто-нибудь знает более простой способ решения проблемы, чем те, что в этом посте?

Answer 1

Я бы поспорил, что решение вашей проблемы состояло бы в том, чтобы установить лучшие практики для модификации исходного кода.

Не дать людям идти в код пользовательского интерфейса и произвольно перемешивать компоненты в конструкторе.Любые разумные модификации интерфейса должны быть легко объединяемыми.Лучше всего попытаться обучить людей наилучшему способу слияния в любой системе контроля версий.Кроме того, как бы ни был полезен дизайнер, незнание того, какой код генерируется автоматически в фоновом режиме, в долгосрочной перспективе будет значительно вредным.

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

Answer 2

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

Еще одна вещь, которую следует учитывать, - это убедиться, что все «получают последние данные» через регулярные промежутки времени, тогда любое отдельное слияние / разрешение не будет таким большим, что сводит к минимуму вероятность того, что что-то пойдет не так.

Возможно, стоит также изучить сторонний инструмент слияния. Вокруг много.

Теперь, возможно, изменения, которые я сделал, просты по сравнению с теми, что у вас есть, поэтому вы должны взять мои анекдотичные данные с щепоткой соли.

Answer 3

Это может вызвать проблемы (в целом), когда много людей редактируют пользовательский интерфейс одновременно. Логика слияния отлично справляется со слиянием, но во многих случаях пользовательский интерфейс рисуется в соответствии с тем, как вещи добавляются в форму. Ваш пользовательский интерфейс может быть испорчен быстро.

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

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

Как уже упоминали другие, помните одно из основополагающих правил SCM: объединяйтесь рано и часто, и ваши проблемы уменьшатся. (наряду с этим «всегда обновляйтесь до начала работы над кодом).