Использование SVN плохо - это Mercurial ответ?

13

На работе мы используем SVN, но только по названию. Мы не разветвляемся и не сливаемся. У нас есть две копии репозитория, одна из которых служит в качестве ветви «тега», которая копируется, когда мы выполняем развертывание, и сохраняется для исправления ошибок и немедленных функций типа «это должно быть как можно скорее». Мы должны помнить, чтобы скопировать изменения, сделанные в одной копии, в другую копию («ствол»). У нас есть дюжина проектов в одной папке в хранилище, вместо того, чтобы разбивать их. Короче говоря, единственное, для чего мы используем SVN - это возможность коммитить. Все остальное делается вручную.

Я оцениваю Mercurial; Я использовал Git в прошлом (я единственный в команде, кто использовал DVCS), и я быстро собираю Mercurial. Я спорю о том, чтобы представить Mercurial остальной части команды как «лучший способ» сделать что-то, потому что ветвление - это совсем несложно, слияние намного проще, и мы можем фиксировать вещи локально, как душе угодно, и только подталкивать их к центральному. ветвь, когда они готовы. Мы получили бы все преимущества SVN (и в настоящее время мы не получаем многих преимуществ, так как никто не понимает SVN), плюс к новым функциям нам не нужно иметь тонны неверсированных файлов, поэтому если нам придется откатываться Мы влипли. Рабочий процесс кажется немного проще - мы просто должны помнить, что «Commit» является локальным, а «Push» похож на SVN,

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

Уэйн Молина
источник
13
HgInit - Это начинается с перевоспитания Subversion, которое, я думаю, вы найдете полезным.
Яннис
20
Вы не боитесь, что они в конечном итоге также будут плохо использовать Hg?
Одед
6
Я думаю, что DVCS была бы ужасной идеей для вашей ситуации, поскольку кривая обучения выше, и вы, как организация, изо всех сил пытаетесь использовать базовые возможности SVN. Переход на DVCS должен происходить только после использования тегов, правильной организации репозитория и правильных методов слияния в SVN и обнаружения того, что его по-прежнему не хватает для ваших нужд.
maple_shaft
2
@WayneM Выбор использования SVN поверх DVCS не обязательно является неправильным. Некоторые люди (включая меня) не испытывают никаких проблем с объединением в SVN и считают, что сложность DVCS перевешивает предполагаемые преимущества, особенно если вы небольшая локализованная команда. Я, вероятно, не буду относиться к DVCS очень серьезно, пока не окажусь в большой команде разработчиков, где объединение является огромной проблемой.
maple_shaft
4
@maple_shaft I will probably not take DVCS very seriously until I end up on a large development teamИли пока вы не окажетесь в распределенной команде. Мы небольшая команда (5 человек), работающая из 3 мест (а иногда и 5, когда нам не хочется вставать с постели), и переход с svn на hg был долгожданным ...
Яннис

Ответы:

15

Да.

Если вы замените «SVN» на «Perforce» в своем OP, вы в значительной степени получите ситуацию, в которой я оказался, когда начал свою текущую работу, даже вплоть до копирования с ручным изменением. Два года спустя мы находимся на Mercurial, и все соглашаются, что это было большим изменением.

У нас есть возможность ветвиться и объединяться в каждом случае поддержки , что невероятно полезно для QA, и возможность создавать любое количество одноразовых веток и репозиториев, когда мы посчитаем нужным, что мы можем затем построить и проверить на нашем сервере CI, а затем развернуть в среду тестирования облака и проверки функциональности. Это принесло огромную пользу с точки зрения душевного спокойствия, так как когда мы выполняем развертывание в режиме реального времени, мы почти на 100% уверены, что оно будет работать (без проблем со средой / БД, которые, очевидно, выходят за рамки VCS).

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

Также есть комментарий к сайту hginit , как набросок рабочего процесса контроля версий, который действительно работает (при условии, что вы настроили его для конкретного рабочего процесса QA вашей компании).

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

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

Эд Джеймс
источник
3
-1, если разработчики уже имеют такие проблемы с Subversion, крайне маловероятно, что они «получат» более сложную систему. Правильный ответ, как говорится в комментариях к вопросу, переобучение того, как работает Subversion (и VCS в целом) ...
Izkata
1
@ EdWoodcock, я думаю, что то, что вы заметили, может быть связано с тем, что ваша команда начала с «чистого листа». Полное изменение VCS на Mercurial означало, что все должны начинать с нуля и больше не могут зависеть от вредных привычек, которые они использовали в SVN. Много раз легче преодолеть вредные привычки «начинать сначала» в другом контексте (в данном случае - ртутный).
Анджело
2
@EdWoodcock: у Perforce может быть худшее разветвление из всех VCS, которые все еще используются. Разветвление в SVN намного проще.
Кевин Клайн
1
Независимо от того, какая система контроля версий используется, я думаю, что важно «установить правила» и потратить время, чтобы обсудить все сценарии использования с вашей командой. Люди не рождаются, зная, как делать ветки, теги и проверки, разные команды делают это по-разному, и системы VCS не навязывают один рабочий процесс другому. Если члены команды не находятся на одной странице с точки зрения ожиданий и использования, контроль версий становится кошмаром. Это проблемы, которые являются общими для ВСЕХ систем VCS.
Анджело
1
@ChrisS Эта притча больше применима к стандартному VCS, где есть стоимость ветвления. Кроме того, речь идет о ветвлении, фиксации и повторном слиянии, что <i> вы делаете каждый раз, когда клонируете </ i> в DVCS. Кроме того, я только что обрисовал, почему этот подход действительно работает для нас; быть догматичным в методологии довольно глупо.
Эд Джеймс
21

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

http://thedailywtf.com/Articles/Source-Control-Done-Right.aspx

Я думаю, что основной смысл статьи здесь обобщен, но, пожалуйста, прочитайте его:

В конце концов: не совсем об инструментах

За все время, что я потратил на работу и интеграцию различных систем контроля версий, я пришел к одному выводу: это не инструмент, а то, как вы его используете. Это ужасно избитое заявление, но здесь оно особенно верно. При использовании для правильного управления изменениями исходного кода - маркировки для сборок, ветвления по исключениям и т. Д. - даже самая слабая система управления исходным кодом (* cough * SourceSafe * cough *) будет намного превосходить установку Mercurial с кучей случайных коммитов и толчки.

Черный лед
источник
6
+1, это действительно не об инструментах. SVN прекрасно способен, как и выступать.
Анджело
1
Это все о людях, а не инструментах. Я видел хорошо управляемые проекты, все еще использующие систему Concurrent Versions System для контроля версий, а также ужасные проекты, работающие с GIT или Mercurial.
Александр Галкин
Дело не в инструментах, если только у вас нет превосходных инструментов, дополняющих провайдера управления исходным кодом, таких как github, bitbucket
Chris S
3
Хотя я согласен с тем, что именно то, как вы используете свои инструменты, имеет значение, это также тот случай, когда разные инструменты ведут вас в разных направлениях. Такие инструменты, как Mercurial, ведут вас по пути простоты и гибкости. Git ведет вас по пути сложности, но чрезвычайно гибко, Subversion делает некоторые вещи легче, чем другие, поэтому уводит вас от сложных и непростых вещей, тогда как Visual Sourcesafe ведет вас по пути чрезвычайной негибкости и головокружительного разочарования. * 8 ')
Марк Бут
10

Нет. Технология редко решает подобные проблемы.

Mercurial более сложен, чем Subversion (да, ветвление и слияние лучше и, возможно, проще, но модель Subversion намного проще, чем Mercurial). Если вы используете Subversion таким разумным способом, вы можете использовать Mercurial:

  • а) адекватно или лучше
  • б) неадекватно, но лучше, чем ваше текущее использование Subversion
  • в) неадекватно, как сейчас
  • г) хуже чем сейчас

в) и г) звучат как наиболее вероятные результаты. Запишите, почему вы думаете, что окажетесь в а) или б).

Алекс
источник
5

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

Брайан Кноблаух
источник
3

Нет. Инструменты не являются заменой методологии.

Если вы не используете Subversion в качестве SCM , вы также не можете использовать Mercurial (и это, скорее всего, произойдет)

Ленивый Барсук
источник
2

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

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

Есть несколько вещей, которые я знаю, люди пытались успешно. Возможно, один из них будет работать на вашу команду:

  1. Приведите «тренера» для проведения серии семинаров для команды. Скорее всего, это должен быть внешний человек (по иронии судьбы, многим командам зачастую легче доверять постороннему, чем доверять кому-то из команды). Это должен быть кто-то, кто знает свои вещи наизнанку и может эффективно обучить этим навыкам людей на всех уровнях понимания и разработать прагматический план по внедрению новой VCS (*) в рабочий процесс команды.

  2. Запустите проект "skunk-works", чтобы протестировать и проверить новую VCS на небольшом стороннем проекте. Выберите пару «альфа» разработчиков, которые готовы попробовать новые вещи и не прочь провести кучу неудачных экспериментов. Когда скунсы смогут продемонстрировать КОНКРЕТНЫЕ неопровержимые улучшения в рабочем процессе, тогда вы можете попытаться распространить это на остальную часть команды, и у вас есть пара евангелистов, которые помогут вам сделать это.

(*) под "новым VCS" я не обязательно имею в виду Mercurial или Git, это также может быть SVN (сделано правильно).

Angelo
источник