Как вы справляетесь со светлой стороной и темной стороной распределенных систем контроля версий?

Question

Недавно у меня были некоторые дискуссии о переходе с Subversion на DVCS, такой как базар, и я хотел бы узнать мнение других людей.

Мне удалось преобразовать свое нежелание сделать это в простую параллель.

Контроль версий может использоваться хорошо или плохо.

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

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

Subversion делает как светлую, так и темную стороны относительно жесткими. Все основы работают, но немногие люди действительно используют ветвление в Subversion (кроме тегов и выпусков), потому что объединение не так просто. Поддержка этого в самой Subversion ужасна, и есть такие скрипты, как svnmerge, которые делают его лучше, но он все еще не очень хорош. Итак, в наши дни, с хорошей поддержкой ветвления и слияния, которая все больше и больше напоминает необходимость совместной разработки, Subversion не подходит.

С другой стороны, «темная сторона» тоже довольно трудна для подражания. Вы должны быть укушены только один раз, если ваши локальные изменения не будут время от времени вноситься в онлайн-хранилище, и нарушать ваш код простым редактированием, которое вы даже не помните. Таким образом, вы делаете регулярные коммиты, и люди могут видеть работу, которую вы делаете.

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

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

Итак, в двух словах, вот вопрос: если я дам нашим разработчикам DVCS, как я могу убедиться, что они используют его, чтобы перейти на «светлую сторону», по-прежнему регулярно публиковать свои изменения в центральном местоположении, и заставить их понять, что их недельный локальный хак, которым они не хотели делиться, может быть тем, что другой разработчик может использовать для завершения функции, пока первый находится в отпуске?

Если и на светлую, и на темную сторону DVCS так легко добраться, как я могу держать их подальше от темной стороны?

Answer 1

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

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

Answer 2

Ник

Хотя я согласен с тем, что проблема заключается в том, чтобы «не делиться своей работой», главный аргумент состоит в том, что инструменты способствуют определенному рабочему процессу, и не все инструменты применимы ко всем проблемам с одинаковым трением. Меня беспокоит то, что DVCS облегчает не делиться вашей работой, поскольку у вас нет недостатков в том, что вы не делитесь своей работой с SVN. Если трение об отсутствии совместного использования меньше, чем трение об отсутствии совместного использования (которое существует в DVCS), разработчик, при прочих равных, может легко выбрать путь наименьшего трения.

Не думаю, что меня смущает контроль над распределенным источником. Я знаю, что по умолчанию нет «центрального местоположения». Но большинство проектов, использующих DVCS, все еще имеют концепцию «главной» ветви в «центральном местоположении», из которого они выпускают. Однако в целях моего вопроса я делаю различие только между ветвями «private» (доступными только для разработчика) и «public» (доступными для всех других разработчиков).

Answer 3

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

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

Answer 4

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