Пожалуйста, договоритесь о проверке и заблокируйте обновление и объединение контроля версий

Question

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

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

Мне не нравится проверять и блокировать, потому что двум и более людям очень трудно работать в одном проекте одновременно. Всякий раз, когда вы добавляете новый файл любого типа или изменяете имя файла, система контроля версий проверяет файл .csproj. Это не позволяет другим разработчикам добавлять / переименовывать файлы.

Я рассматривал создание только .csproj файла как слияния, но сайт Sourcegear говорит, что это плохая идея, потому что csproj генерируется IDE автоматически и что вы не можете гарантировать, что два разных файла, сгенерированных VS, будут создавать один и тот же код .

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

Я считаю, что правильное решение - перейти на модель с возможностью слияния. Мой ответ на проблему «файлов ренегатов» заключается в том, что это была проблема плохой дисциплины программиста, и что вы не должны использовать более слабый выбор программиста как исправление для плохой дисциплины; вместо этого вы должны принять меры, чтобы устранить недостаток дисциплины программиста.

Так, кто прав? Является ли регистрация - проверить законный ответ на вопрос файла ренегатов? Или проблема .csproj слишком сложна для нескольких разработчиков? Или Sourcegear не прав и что все в порядке, чтобы установить csproj файл для обновления и слияния?

Answer 1

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

Я думаю, что ваш технический анализ различий между двумя методологиями контроля версий является правильным, и я согласен, что обновление / слияние лучше. Но я думаю, что реальная проблема заключается в общении с людьми в вашей группе (группах), и как это становится очевидным при использовании контроля версий, и в том, знакомы ли люди в группах с процессом контроля версий, которым вы владеете ». мы выбрали. Заметьте, что когда я это говорю, моя собственная группа на работе испытывает те же трудности, только с Agile / SCRUM вместо VC. Это больно, это раздражает, это расстраивает, но хитрость (я думаю) заключается в том, чтобы определить корневую проблему и исправить ее.

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

Answer 2

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

Слияние часто означает, что каждое слияние мало, что очень помогает. Часто помогает тестирование как на отдельных кодовых базах, так и на ночных проверках из хранилища.

Answer 3

1. Используйте правильную систему контроля версий (svn, mercurial, git, ...)
2. Если вы собираетесь делать много ветвлений, не используйте ничего менее свежего, чем SVN 1.6. Я предполагаю, что mercurial / git был бы еще лучшим решением, но у меня пока не так много практического опыта их использования.
3. Если люди постоянно работают над одними и теми же частями системы, рассмотрите проект системы. Это указывает на то, что у каждого подразделения слишком много ответственности.
4. Никогда, никогда не принимайте людей в автономный режим более чем на день или около того. Исключения из этого правила должны быть крайне редкими.
5. Поговорите друг с другом. Сообщите другим разработчикам, над чем вы работаете.

Лично я бы не использовал файлы проекта в моем хранилище. Но опять же, я бы никогда не привязал разработчиков к одному инструменту. Вместо этого я бы использовал систему сборки, которая генерировала файлы проекта / makefiles / что угодно (CMake - мой вкус для этого).

РЕДАКТИРОВАТЬ: Я думаю, блокировка файлов устраняет симптомы, а не болезнь. В конечном итоге разработчики ничего не будут делать, если это станет привычкой.

Answer 4

Я менеджер по развитию небольшой компании, всего 3 программиста. Проекты, над которыми мы работаем, иногда занимают недели, и мы применяем стиль реализации большого взрыва, шока и страха. Это означает, что у нас есть много изменений базы данных и программ, которые должны отлично работать в ту ночь, которую мы внедряем. Мы извлекаем из программы программу, меняем ее и откладываем в сторону, потому что реализация ее до того, как все остальное заставит взорвать 20 других вещей. Я для проверки и блокировки. В противном случае другой человек может изменить несколько вещей, не осознавая, что в программе уже произошли значительные изменения. И объединение помогает, только если вы не внесли изменения в базу данных или изменения в других системах, не находящихся под контролем источника. (Microsoft CRM, в основном любое упакованное программное обеспечение, расширяемое с помощью конфигурации)

Answer 5

Мы используем subversion без каких-либо ограничений на регистрацию / извлечение любых файлов в высокопараллельной среде. Я согласен с тем, что вопрос о файлах отступников - это вопрос дисциплины. Отказ от слияния не решает основную проблему. Что мешает разработчику копировать собственную «исправленную» копию кода поверх обновлений других людей?

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

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

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

Answer 6

IMO, файлы проекта, такие как .csproj, не должны быть частью системы управления версиями, поскольку они на самом деле не являются исходными.

Они также почти наверняка не являются объединяемыми.