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

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

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

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

Да.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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