Я пытаюсь понять преимущества распределенной системы контроля версий (DVCS).

Я нашел Subversion переобучения и эту статью на Мартина Фаулера очень полезным.

Mercurial и другие DVCS продвигают новый способ работы с кодом с помощью наборов изменений и локальных коммитов. Это предотвращает от слияния ада и других проблем сотрудничества

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

Mercurial позволяет иметь лейтенантов

Я понимаю, что это может быть полезно для очень больших проектов, таких как Linux, но я не вижу смысла в небольших и тесно сотрудничающих командах (от 5 до 7 человек).

Mercurial работает быстрее, занимает меньше места на диске, а полное локальное копирование позволяет быстрее выполнять операции регистрации и сравнения.

Меня это тоже не касается, так как я не заметил проблем со скоростью или пространством в SVN даже с очень большими проектами, над которыми я работаю.

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

ОБНОВЛЕНИЕ (12 января) : Теперь я убежден, что стоит попробовать.

ОБНОВЛЕНИЕ (12 июня) : я поцеловал Mercurial, и мне понравилось. На вкус его вишневые местные коммиты. Я поцеловал Mercurial, чтобы попробовать. Надеюсь, мой SVN-сервер не против. Это было так неправильно. Это было так хорошо. Не значит, что я влюблен сегодня вечером .

ЗАКЛЮЧИТЕЛЬНОЕ ОБНОВЛЕНИЕ (29 июля) : Я имел честь просмотреть следующую книгу Эрика Синка « Контроль версий на примере» . Он закончил, чтобы убедить меня. Я пойду на Mercurial.

Примечание. См. «РЕДАКТИРОВАТЬ» для ответа на текущий вопрос.

Прежде всего, прочитайте Subversion Re- Education Джоэла Спольски. Я думаю, что на большинство ваших вопросов там ответят.

Другая рекомендация, выступление Линуса Торвальдса на Git: http://www.youtube.com/watch?v=4XpnKHJAok8 . Этот другой может также ответить на большинство ваших вопросов, и это довольно занимательный.

Кстати, кое-что я нахожу довольно забавным: даже Брайан Фитцпатрик и Бен Коллинз-Суссман, два из первых создателей Subversion, сказали в одном из выступлений Google «извините за это», ссылаясь на то, что Subversion уступает Mercurial (и DVCS в целом).

Теперь, IMO и в целом, командная динамика развивается более естественно с любой DVCS, и выдающимся преимуществом является то, что вы можете фиксировать в автономном режиме, потому что это подразумевает следующие вещи:

• Вы не зависите от сервера и соединения, что означает более быстрые времена.
• Не быть рабом тех мест, где вы можете получить доступ к Интернету (или VPN), чтобы иметь возможность совершать коммиты.
• У каждого есть резервная копия всего (файлы, история), а не только сервер. То есть любой может стать сервером .
• Вы можете совершать компульсивно, если вам нужно, не мешая чужому коду . Комитеты местные. Вы не наступаете на пальцы друг друга, совершая. Вы не нарушаете сборки или окружение других, просто совершая действия.
• Люди без «коммитного доступа» могут коммитить (потому что коммитирование в DVCS не подразумевает загрузку кода), снижая барьер для вкладов, вы можете принять решение об их изменениях или нет как интегратор.
• Это может усилить естественное общение, так как DVCS делает это существенным ... в подрывной деятельности вы вместо этого получаете коммитные расы, которые форсируют общение, но мешают вашей работе.
• Участники могут объединиться и справиться с собственным слиянием, что в конечном итоге означает меньшую работу для интеграторов.
• Участники могут иметь свои собственные ветви, не влияя на чужие (но имея возможность делиться ими при необходимости).

О ваших баллах:

• Ад слияния не существует в DVCSland; не нужно обрабатывать Смотрите следующий пункт .
• В DVCS каждый представляет «ветвь», то есть при каждом изменении происходят слияния. Именованные ветви - это другое.
• Вы можете продолжать использовать непрерывную интеграцию, если хотите. Хотя не обязательно, зачем добавлять сложность? Просто продолжайте тестирование как часть своей культуры / политики.
• Mercurial быстрее в некоторых вещах, git быстрее в других. Не совсем до DVCS в целом, но до их конкретной реализации AFAIK.
• У каждого всегда будет полный проект, а не только у вас. Распределенная вещь связана с тем, что вы можете фиксировать / обновлять локально, обмен / получение извне вашего компьютера называется push / pull.
• Опять же, прочитайте Subversion Re-Education. DVCS проще и естественнее, но они разные, не пытайтесь думать, что cvs / svn === основа всех версий.

Я вносил некоторую документацию в проект Joomla, чтобы помочь проповедовать переход на DVCS, и здесь я сделал несколько диаграмм, чтобы проиллюстрировать централизованное и распределенное распределение.

централизованные

Распространены в общей практике

Распределяется в полной мере

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

Теперь это типичный рабочий процесс для проектов с открытым исходным кодом (например, проекта с широким сотрудничеством) с использованием DVCS:

Bitbucket.org - это своего рода эквивалент github для mercurial, знайте, что у них есть неограниченное количество частных репозиториев с неограниченным пространством, если ваша команда меньше пяти, вы можете использовать ее бесплатно.

Лучший способ убедить себя в использовании DVCS - это попробовать DVCS. Каждый опытный разработчик DVCS, который использовал svn / cvs, скажет вам, что оно того стоит, и что они не знают, как они выжили без него все свое время.

РЕДАКТИРОВАТЬ : Чтобы ответить на ваше второе редактирование, я могу еще раз повторить, что с DVCS у вас есть другой рабочий процесс, я бы посоветовал вам не искать причины, чтобы не попробовать его из-за лучших практик , такое чувство, что когда люди утверждают, что ООП не является необходимо, потому что они могут обойти сложные шаблоны проектирования с тем, что они всегда делают с парадигмой XYZ; Вы можете извлечь выгоду в любом случае.

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

Что касается «сливающегося ада», вы говорите «если мы не экспериментируем», я говорю «даже если вы экспериментируете + продолжаете работать + в обновленной версии 2.0 одновременно ». Как я говорил ранее, ад слияния не существует, потому что:

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

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

Относительно того, как работают наборы изменений и повышение производительности. Я попытаюсь проиллюстрировать это на примере, который мне нравится приводить: переключение проекта mootools с svn показано на их графике сети github .

До

После

Что вы видите, так это то, что разработчики могут сосредоточиться на своей работе во время коммиттинга, не опасаясь взломать чужой код, они беспокоятся о взломе чужого кода после нажатия / вытягивания (DVCS: сначала зафиксировать, затем нажать / вытянуть, затем обновить ) но так как слияние здесь более разумно, они часто этого не делают ... даже когда возникает конфликт слияния (который встречается редко), вы потратите на его устранение не более 5 минут.

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

Наконец, я бы порекомендовал вам использовать mercurial + bitbucket вместо git + github, если вы работаете с людьми из Windows. Mercurial также немного проще, но git более мощный для более сложного управления репозиторием (например, git rebase ).

Некоторые дополнительные рекомендуемые чтения:

• Распределенные системы контроля версий: Git против Mercurial против SVN
• Git vs. Mercurial: пожалуйста, расслабься
• Распределенный контроль версий и Git [Часть 1] и Распределенный контроль версий и Git [Часть 2]
• Git / Mercurial против Subversion: Бой!
• DVCS против Subversion, 3 раунда
• Почему я люблю Mercurial больше, чем Git ( часть 1 , часть 2 )
• Содействие с Git: Сокращение трения сотрудничества с открытым исходным кодом с Git VCS
• "Как DVCS работали для вас до сих пор?" - пост на Joomla! Список рассылки Framework Development с просьбой дать обратную связь после экспериментального принятия Mercurial и Git для Joomla! Платформа Проект
• Разветвление DVCS (с Mercurial) - подробное и ориентированное на пример введение в то, как выглядит разветвление в DVCS, что, возможно, является наиболее важной функцией в этих системах.

Вы говорите, среди прочего, что если вы, по сути, остаетесь в одной ветке, вам не нужен распределенный контроль версий.

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

DVCS - это Subversion, что такое Bittorrent для ftp

(технически, а не юридически). Возможно, если вы обдумаете это, вы поймете, почему это такой большой скачок вперед?

Для меня наш переход на git, сразу же привел к

• Наши резервные копии легче сделать (просто «git remote update», и все готово)
• Проще совершать небольшие шаги при работе без доступа к центральному хранилищу. Вы просто работаете и синхронизируетесь, когда возвращаетесь в сеть, в которой находится центральный репозиторий.
• Быстрее строит Хадсон. Гораздо быстрее использовать git pull, чем обновлять.

Итак, подумайте, почему bittorrent лучше, чем ftp, и пересмотрите свою позицию :)

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

Особенностью убийцы распределенных систем контроля версий является распределенная часть. Вы не извлекаете «рабочую копию» из хранилища, вы клонируете целую копию хранилища. Это огромно, так как дает мощные преимущества:

• Вы можете пользоваться преимуществами контроля версий, даже если у вас нет доступа к Интернету, например ... Этот, к сожалению, используется слишком часто и перегружен, что является причиной того, что DVCS является удивительным - он просто не является сильной стороной продаж, поскольку многие из мы обнаруживаем, что кодируем без доступа в Интернет примерно так же часто, как начинается дождь лягушек.

• Истинная причина наличия локального репозитория в том, что вы имеете полный контроль над историей коммитов, прежде чем она будет отправлена ​​в главный репозиторий .

Всегда исправлял ошибку и получал что-то вроде:

r321 Fixed annoying bug.
r322 Argh, unexpected corner case to annoying bug in r321!
r323 Ok, really fixed corner case in r322
r324 Oops, forgot to remove some debugging code related to r321
...

И так далее. Подобная история беспорядочная - на самом деле было только одно исправление, но теперь реализация распределена между многими коммитами, которые содержат нежелательные артефакты, такие как добавление и удаление операторов отладки. С такой системой, как SVN, альтернатива - не фиксировать (!!!), пока все не заработает, чтобы сохранить историю в чистоте. Даже в этом случае ошибки просачиваются, и закон Мерфи ждет, чтобы вас зверски изобразить, когда значительные объемы работы не защищены контролем версий.

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

r321 Fixed annoying bug.

Как это и должно быть.

Способность переписывать историю еще более эффективна в сочетании с моделью ветвления. Разработчик может выполнять работу, которая полностью изолирована внутри ветви, а затем, когда приходит время перенести эту ветку в ствол, у вас есть все виды интересных вариантов:

• Сделайте простое ванильное слияние . Приносит все в бородавки и все.

• Сделай ребаз . Позволяет вам сортировать историю веток, переупорядочивать порядок коммитов, выбрасывать коммиты, объединять коммиты, переписывать сообщения коммитов - даже редактировать коммиты или добавлять новые! Распределенная система контроля версий имеет глубокую поддержку анализа кода.

Когда я узнал, что локальные репозитории позволяют мне редактировать мою историю ради здравомыслия моих коллег-программистов и моего будущего Я, я повесил SVN навсегда. Мой клиент Subversion сейчас git svn.

Позволение разработчикам и менеджерам осуществлять редакторский контроль над историей коммитов приводит к улучшению истории проекта, а наличие чистой истории для работы действительно помогает моей продуктивности как программиста. Если все эти разговоры о «переписывании истории» вас пугают, не волнуйтесь, для этого нужны центральные, публичные или главные репозитории. История может (и должна!) Быть переписана до того момента, когда кто-то внесет ее в ветку в хранилище, из которого другие люди тянут. На этом этапе история должна рассматриваться как вырезанная на каменной табличке.

Ответ dukofgamings, вероятно, настолько хорош, насколько это возможно, но я хочу подойти к этому с другой стороны.

Давайте предположим, что то, что вы говорите, абсолютно верно, и что, применяя передовой опыт, вы сможете избежать проблем, которые DVCS был разработан для решения. Значит ли это, что DVCS не предложит вам никаких преимуществ? Люди воняют от следующих лучших практик. Люди собираются испортить. Так почему бы вам не использовать программное обеспечение, разработанное для решения ряда проблем, вместо этого полагаясь на то, что люди будут делать то, что вы можете заранее предсказать, что они не собираются делать?

Да, это больно, когда вам приходится объединять большие коммиты в Subversion. Но это также отличный учебный опыт, позволяющий вам сделать все возможное, чтобы избежать слияния конфликтов. Другими словами, вы учитесь регистрироваться часто . Ранняя интеграция - очень хорошая вещь для любого совместного проекта. Пока все так делают, использование subversion не должно быть большой проблемой.

Git, например, был разработан для распределенной работы и поощряет людей работать над своими собственными проектами и создавать собственные вилки для (возможного) слияния позже. Он не был специально разработан для непрерывной интеграции в «маленькие и тесно сотрудничающие команды», о чем просит OP. Это скорее наоборот, если подумать. Вы не будете использовать его необычные распределенные функции, если все, что вы делаете - сидите в одной комнате и работаете вместе над одним и тем же кодом.

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

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

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

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

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

С другой стороны, git не позволяет вам переходить на отдельные уровни каталогов, как это делает subversion.

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

Что касается производительности, Git или любая другая DVCS имеет большое преимущество перед SVN, когда вам нужно переключиться с одной ветви на другую или перейти с одной ревизии на другую. Поскольку все хранится локально, все гораздо быстрее, чем для SVN.

Одно это может заставить меня переключиться!

Вместо этого придерживаясь идеи, что «применяя лучшие практики, вам не нужен DVCS», почему бы не подумать, что рабочий процесс SVN - это один рабочий процесс с одним набором лучших практик, а рабочий процесс GIT / Hg - это другой рабочий процесс, с другим набором лучших практик.

git bisect (и все его последствия для вашего основного хранилища)

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

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

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

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

Gitworkflows страница человек является хорошим введением в рабочие процессы , которые Git предназначены. Также, почему Git лучше X обсуждает рабочие процессы git.

Большие, распределенные проекты

Зачем нам нужны лейтенанты в высококвалифицированной команде с хорошими практиками и хорошими дизайнерскими привычками?

Потому что в таких проектах, как Linux, есть так много людей, которые настолько географически распределены, что трудно быть столь же тесно сотрудничающим, как небольшая команда, которая разделяет конференц-зал. (Я подозреваю, что для разработки такого крупного продукта, как Microsoft Windows, даже если все люди находятся в одном здании, команда слишком велика, чтобы поддерживать уровень совместной работы, благодаря которому централизованная VCS работает без лейтенантов.)

Почему бы не использовать их в тандеме? В моем текущем проекте мы вынуждены использовать CVS. Однако мы также храним локальные репозитории git для разработки функций. Это лучшее из обоих миров, потому что вы можете попробовать различные решения и сохранить версии того, над чем вы работаете, на своей собственной машине. Это позволяет вам откатиться к предыдущим версиям вашей функции или попробовать несколько подходов, не вдаваясь в проблемы, когда вы портите свой код. Наличие центрального хранилища дает вам преимущества наличия централизованного хранилища.

У меня нет личного опыта работы с DVCS, но из того, что я понял из ответов здесь и некоторых связанных документов, наиболее фундаментальное различие между DVCS и CVCS - это используемая рабочая модель.

DVCS

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

CVCS

Рабочая модель CVCS (в частности, Subversion) заключается в том, что вы делаете совместную разработку . Вы разрабатываете новую функцию / исправление в непосредственном сотрудничестве со всеми остальными членами команды, и все изменения сразу становятся доступны всем.

Другие отличия

Другие различия между svnи git/ hg, например, редакции и наборы изменений, являются случайными. Очень хорошо можно создать DVCS на основе ревизий (как у Subversion) или CVCS на основе наборов изменений (как у Git / Mercurial).

Я не собираюсь рекомендовать какой-либо конкретный инструмент, потому что он в основном зависит от рабочей модели, которая вам (и вашей команде) наиболее удобна.
Лично у меня нет проблем с работой с CVCS.

• Я не боюсь проверять вещи, так как у меня нет проблем с получением их в неполном, но компилируемом состоянии.
• Когда я испытал ад слияния, это было в ситуациях, когда это произошло бы в обоих svnи git/ hg. Например, V2 некоторого программного обеспечения поддерживалась другой командой, использующей другую VCS, в то время как мы разрабатывали V3. Иногда исправления ошибок нужно было импортировать из V2 VCS ​​в V3 VCS, что в основном означало очень большую проверку V3 VCS (со всеми исправлениями в одном наборе изменений). Я знаю, что это не было идеальным, но это было управленческое решение использовать различные системы VCS.