Я подражатель Subversion, почему я должен рассматривать или не рассматривать Mercurial или Git или любые другие DVCS?

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

Я нашел переподготовка Subversion и Мартин Фаулер очень полезен.

  

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

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

  

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

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

  

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

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

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

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

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

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

297 голосов | спросил user2567 9 Jpm1000000pmSun, 09 Jan 2011 16:51:19 +030011 2011, 16:51:19

10 ответов


327

Примечание: см. «ИЗМЕНИТЬ» для ответа на текущий вопрос


Прежде всего, прочитайте переподготовку Subversion Joel Spolsky. Я думаю, что на большинство ваших вопросов будет дан ответ.

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

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

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

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

О ваших точках:

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

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

Централизованная

alt text

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

alt text

Распространяется в полном объеме

alt text

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

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

alt text

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

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


EDIT . Чтобы ответить на второе редактирование, я могу просто повторить, что с помощью DVCS у вас есть другой рабочий процесс, я бы посоветовал вам не искать причины, чтобы не попробовать его из-за лучшие практики , эточувствует, когда люди утверждают, что ООП не является необходимым, потому что они могут обойти сложные шаблоны проектирования с тем, что они всегда делают с парадигмой XYZ; вы можете выиграть в любом случае.

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

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

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

alt text

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

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

До

alt text

После

alt text

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

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

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

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

ответил dukeofgaming 9 Jpm1000000pmSun, 09 Jan 2011 17:37:56 +030011 2011, 17:37:56
58

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

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

DVCSes - это Subversion, что Bittorrent для ftp

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

Для меня наш переключатель в git сразу привел к

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

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


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

ответил 9 Jpm1000000pmSun, 09 Jan 2011 21:56:40 +030011 2011, 21:56:40
44

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

  • Вы можете пользоваться преимуществами контроля версий, даже если у вас нет доступа к Интернету, например ... Этот, к сожалению, чрезмерен и чрезмерен, по причине того, что 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, альтернатива заключается в not commit (!!!), пока все не будет работать, чтобы сохранить историю чистой. Даже тогда ошибки проскальзывают, и закон Мерфи ждет зверства, когда значительное количество работ не защищено контролем версий.

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

r321 Fixed annoying bug.

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

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

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

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

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

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

ответил Sharpie 10 Jam1000000amMon, 10 Jan 2011 00:42:08 +030011 2011, 00:42:08
18

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

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

ответил philosodad 9 Jpm1000000pmSun, 09 Jan 2011 18:20:16 +030011 2011, 18:20:16
9

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

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

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

ответил Martin Wickman 9 Jpm1000000pmSun, 09 Jan 2011 19:02:24 +030011 2011, 19:02:24
8

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

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

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

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

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

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

ответил Pete 22 Jpm1000000pmSat, 22 Jan 2011 14:51:10 +030011 2011, 14:51:10
7

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

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

ответил Xavier Nodet 9 Jpm1000000pmSun, 09 Jan 2011 23:28:55 +030011 2011, 23:28:55
3

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

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

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

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

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

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

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

Крупные, распределенные проекты

  

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

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

ответил Ken Bloom 9 Jpm1000000pmSun, 09 Jan 2011 20:47:07 +030011 2011, 20:47:07
2

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

ответил Vadim 9 Jpm1000000pmSun, 09 Jan 2011 19:16:58 +030011 2011, 19:16:58
1

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

DVCS

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

ЦВК

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

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

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

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

  • Я не боюсь проверять материал, так как у меня нет проблем с его получением в неполное, но компилируемое состояние.
  • Когда я испытал слияние-ад, это было в ситуациях, когда это могло произойти как в svn, так и в git /hg. Например, V2 некоторого программного обеспечения поддерживался другой командой, используя другую VCS, в то время как мы разрабатывали V3. Иногда исправления должны были быть импортированы из V2 VCS ​​в V3 VCS, что в основном означало выполнение очень большой регистрации на V3 VCS (со всеми исправлениями в одном наборе изменений). Я знаю, что это не идеальное решение, но было принято решение использовать разные системы VCS.
ответил Bart van Ingen Schenau 10 Jpm1000000pmMon, 10 Jan 2011 18:10:42 +030011 2011, 18:10:42

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132