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

300

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

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

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

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

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

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

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

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

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

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

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

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

Робин Мабен
источник
8
Я тоже очень заинтересован в этом. Subversion соответствует тому, как меня учили думать о контроле версий (пришедшем из CVS и т.п.). Тем не менее, хотя мне пришлось использовать Mercurial и Git, чтобы попытаться исправить некоторые ошибки в проектах с открытым исходным кодом, я еще не был преобразован.
Берин Лорич
29
+1 за вопрос. В настоящее время он стал культовым грузом, который распространяется лучше, быстрее, проще, естественнее и без проблем, и на 90% сияет по сравнению с централизованным. За исключением того, что это не обязательно. Это разные инструменты, и у каждого из них могут быть преимущества в некоторых контекстах и ​​недостатки в других контекстах.
Joonas Pulakka
17
@Sharpie: Использовав как svn, gitи в hgтечение многих лет, я очень хорошо знают свои плюсы и минусы. Хотя gitэто, безусловно, самый мощный из них, важно признать, что более мощный не означает автоматически лучшее . Emacs, безусловно, более мощный, чем любой текстовый редактор javascript, работающий в веб-браузере, но, как ни странно, я сейчас пишу этот комментарий в текстовый редактор javascript-браузера! Простота , даже глупость, имеет значение во многих контекстах. Использование централизованного svnи чего-то подобного git-svnлокально предлагает лучшее из обоих миров.
Joonas Pulakka
9
@ Шарпи: Это хорошо, что тебе нравится. Но профессионал одного мужчины - это обман другого человека. Некоторые люди считают чистоту единого централизованного хранилища с одним каноническим стволом невероятно ценной. Вот презентация о том, как Google хранит исходный код всех своих проектов (более 2000) в единой ветви кода, содержащей сотни миллионов строк кода, и более 5000 разработчиков получают доступ к одному и тому же хранилищу. Вы бы предпочли 5000 серверов и историю 2000 проектов у всех на столе? -)
Joonas Pulakka
21
-1 для ссылки Кэти Перри. ;)
Amadiere

Ответы:

331

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


Прежде всего, прочитайте 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 ).

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

dukeofgaming
источник
18
Отличный ответ, но только один вопрос для тех из нас, кто находится в той же лодке, что и OP: можете ли вы объяснить, как не существует ад слияния? Разве интегратору или вкладчику не нужно выполнять одни и те же действия, когда их форк устарел?
Николь
17
Хороший ответ. Еще одно замечание: хотя у Спольского могут быть некоторые приятные моменты, имейте в виду, что он также пытается продать продукт, используя эти очки в качестве продающего материала, что делает их немного предвзятыми.
Мартин Уикман
5
Я прочитал эту страницу перевоспитания и не нашел ее актуальной по многим причинам. Я отредактирую свой вопрос с моим личным взглядом на предмет.
15
Стоит также отметить, что Git может выступать в качестве клиента Subversion, а это означает, что вам не нужно конвертировать всех в Git одновременно; несколько членов команды могут просто использовать Git, если им нравится, и их индивидуальный рабочий процесс улучшается (особенно потому, что объединение намного проще).
Greyfade
6
@Pierre, DVCS заботится о слиянии изменений программного обеспечения с отдельными программистами, но не о том, чтобы заставить программное обеспечение компилировать или проходить существующие модульные тесты. Вам все еще нужно другое программное обеспечение, чтобы делать это всякий раз, когда меняется источник, и лучшая ставка, которую мы имеем в наши дни, - это использование CI-движка (и правильное выполнение)
59

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

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

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

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

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

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

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


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


источник
Я почти решил попробовать это с реальным проектом.
Хорошая идея. Не забудьте войти в это с мышлением "Мне действительно нравится это!" вместо «я не хочу делать это!». Есть чему поучиться. Если вы выбираете git, у github есть много хороших онлайн-справок. Если вы выберете hg, Джоэл написал хороший онлайн-материал. Если вы выберете bzr, скорее всего, в Canonical есть много хороших онлайн-материалов. Другие?
3
Хм, это предполагает, что вы думаете, что bittorrent лучше, чем FTP ...
Murph
2
@ Мерф, и я, и Blizzard (и я думаю, что мы можем договориться, знает, как справиться с массовой онлайн-синхронизацией?). wowwiki.com/Blizzard_Downloader
2
@Murph, вы запускаете торрент-сервер на сервере и торрент-клиент на клиенте. Не трудно. Следует немедленно купить вам, что только файлы, которые были изменены, должны быть обновлены. Кроме того, вы подумали, что rsync вместо ftp может купить вас для дополнительных обновлений?
46

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

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

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

остроносая плоскодонная шлюпка
источник
6
Переписывая историю: это просто вещь Git? Или в Mercurial тоже легко? (Если это так, мне действительно нужно начать это делать.)
Пол Д. Уэйт
3
При этом следует помнить о дисциплине «Ядро Linux», а именно: никогда не перезагружать (или переписывать историю) ветку, опубликованную вами публично. Если у вас есть открытые ветки для кратковременного использования (для слияния с ветками, которые часто выбрасываются, например, linux-next, или для того, чтобы кто-то просматривал и затем выбрасывал их локальные копии), вы можете перебазировать эти ветки - но ваши другим пользователям должно быть ясно, что соглашение для этой ветви заключается в том, что ее можно перебазировать и не следует объединять с долгосрочными ветвями других людей.
Кен Блум
4
у вас вполне может быть доступ к Интернету без полного доступа к внутренней сети. Это часто случается со мной во время путешествий.
5
Отсутствие доступа к интернету - это очень большая проблема, потому что отсюда и скорость DVCS. Как только вы отправляете пакеты по сети, вы замедляете процесс примерно на порядок, независимо от того, насколько хорошо ваше соединение.
Адам Лассек
6
@ Пол, я понимаю, что в Mercurial это можно сделать, но это не базовая функциональность или философия.
Бенджол
18

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

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

philosodad
источник
2
На самом деле я бы предложил этот аргумент против DCVS. Моя компания недавно перешла на Mercurial с CVS. Люди стирают изменения других людей во время слияний гораздо чаще, когда на CVS.
Юозас Контвайнис
@JuozasKontvainis: я не очень хорошо знаю Mercurial, но в git вы можете запретить толчки, которые включают в себя слияния, в которых родитель не имеет HEAD, что не позволяет пользователям выдвигать изменения, в которые не включены самые последние изменения из master. Я уверен, что есть что-то подобное в Mercurial.
naught101
@ naught101: на самом деле в моей компании этот параметр включен. Что происходит, так это то, что программист фиксирует свои изменения локально, а затем пытается нажать. Он получает ответ от сервера, что ему нужно слить, прежде чем он сможет нажать. Он получает обновления с сервера и пытается сделать коммит слияния. На данный момент я не знаю точно, как эти люди сделали коммит слияния, но в некоторых случаях коммит слияния в основном стирал изменения, полученные с сервера.
Юозас Контвайнис
1
Похоже, что люди извлекли изменения, а затем фактически удалили изменения, которые они получили с сервера при слиянии (что возможно). Конечно, набор изменений с сервера все еще там, так что вы можете сбросить репозиторий в состояние, в котором он находился до их изменения.
Philododad
1
на самом деле, это звучит так: randyfay.com/content/avoiding-git-disasters-gory-story хорошая, некритическая статья о том, что может пойти не так с репозиторием git, если вы не знаете, что делаете.
gbjbaanb
9

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

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

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

Мартин Викман
источник
2
Git был разработан для распределенной работы по всему миру и поощряет людей работать над своими собственными проектами и создавать собственные вилки. Он не был специально разработан для непрерывной интеграции в «небольшие и тесно сотрудничающие команды», о чем просит OP.
Мартин Уикман,
4
Угадайте, что вы получите меньшие / более простые конфликты для решения. Но если два человека меняют одни и те же части кода, у вас в команде есть проблема планирования , которая не может быть решена ни одной VCS. Распределен или нет.
Мартин Уикман,
4
ОП находится в совместной команде, использующей КИ. Это означает, что они часто делают много небольших проверок (несколько раз в день). Учитывая это, я не вижу причин, по которым использование dvcs должно давать какое-то конкретное преимущество, и я не вижу причин, по которым должны происходить какие-либо огромные слияния и, следовательно, никакого ада слияния. Я бы не рекомендовал svn для распределенной команды, но здесь это не так.
Мартин Уикман,
2
@MartinWickman - Mercurial был разработан для фиксации, ветвления и слияния быстро и дешево. Это звучит идеально для непрерывной интеграции. Лично я считаю, что возможность Алисы разветвлять свои изменения и предлагать Бобу вытянуть их и объединить свои изменения с этой веткой, чтобы проверить наличие проблем - и все это без прикосновения к центральному серверу или перемещения изменений в любом месте - звучит как отличный способ для небольших и тесно сотрудничающих команд для работы.
Философия
2
Мои $ 0,02. Я использовал Subversion, Mercurial и Git для различных проектов. Subversion действительно кажется лучшим выбором для очень тесно интегрированной группы, занимающейся непрерывной интеграцией. Mercurial лучше подходит для групп, которые могут делать только одну сборку в день с гораздо большим количеством изменений кода каждый раз (что может создать проблемы слияния в SVN). Git кажется подходящим вариантом для людей, у которых есть команды, которые могут работать дни и недели, фактически не объединяя код для создания сборки.
Брайан Кноблаух
8

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

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

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

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

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

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

Пит
источник
Совершенно верно, экспериментальные альтернативы должны быть автоматическими.
git использует определенную эвристику, чтобы определить, перемещен ли файл, это хорошо, но не идеально.
gbjbaanb
Согласитесь с этим, даже если вы ненавидите новый инструмент, которым пользуются эти чертовы дети, я думаю, что важно заставить себя хотя бы попробовать что-то новое, особенно если эти вещи создают огромные волны.
Тьяарт
7

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

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

Ксавье Ноде
источник
Согласитесь, Git Checkout очень быстро.
+1 за указание на то, что переход между ветками /
наборами
3

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

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

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

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

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

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

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

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

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

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

Кен Блум
источник
Я не понимаю вашу первую мысль. У вас есть ссылки? Что касается последнего, я бы вместо этого разделил проект на отдельные компоненты. Я никогда не работал над таким большим проектом, максимальное количество разработчиков, которых я получил в одном проекте, составляет два десятка.
@Pierre. Разумеется, разумно разделить проект на отдельные компоненты. Поскольку Linux является монолитным ядром, это означает (по существу), что все драйверы устройств должны разрабатываться в одном и том же репозитории, хотя каждый из них по сути является отдельным проектом. В то же время они хотят, чтобы их более опытные архитекторы ловко вносили широкомасштабные изменения, затрагивающие все эти драйверы, поэтому разбивать их на разные репозитории будет непросто. Так что мерзавцы (и лейтенанты) подходят им для решения этих разных задач.
Кен Блум
Вам также может быть интересно узнать, что говорит Мартин Фаулер о рабочих процессах SVN и Git и Mercurial. martinfowler.com/bliki/VersionControlTools.html
Кен Блум,
2
Я делаю пополам на SVN регулярно, чтобы найти ошибки. Единственная разница с Git в том, что он не полностью автоматический. Но одного этого было бы недостаточно для нас, чтобы переключиться.
Ксавье Нодет
1
Актуальность git bisect для небольших команд почти равна нулю. Я понял это для ядра, где сотни изменений от разных людей объединяются одновременно и ломают вещи, но когда у вас есть команда из 5 человек, вы обычно можете устранить все, кроме 2-3 потенциальных патчей виновника, быстро взглянув на журнал.
blucz
2

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

Вадим
источник
Но вы можете просто настроить центральный репозиторий с DVCS (и вы можете контролировать разрешения так же строго, как с CVCS. Так в чем преимущества?
naught101
Да, но центральные git-репозитории могут быть сложны в настройке, если вы находитесь в среде Windows. Полагаю, это единственное, о чем я мог подумать. Мы были вынуждены использовать CVS на корпоративном уровне, поэтому у нас не было особого выбора.
Вадим
1

У меня нет личного опыта работы с 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.
Барт ван Инген Шенау
источник
Я не думаю, что изолированная разработка на самом деле является рабочей моделью DVCS. Одной из важных особенностей DVCS является то, что другие члены команды могут извлекать ваши локальные изменения или клонировать ваш локальный репозиторий. Вы фиксируете, когда хотите, ваши изменения всегда доступны, и ваши ошибки не могут вызвать массовый хаос.
Философия
@philosodad: Если другие извлекают код из моего хранилища, не зная состояния этого кода, это все равно может вызвать хаос. Разница лишь в том, чья это ответственность. И мой код не всегда доступен. Это все еще зависит от того, настроены ли мои системы для внешнего доступа.
Барт ван Инген Шенау
Если люди извлекают код из вашего хранилища и объединяют его со своим собственным, они могут выполнить откат самостоятельно, без каких-либо массовых проблем. Во-вторых, конечно, если вы примете решение об отказе в доступе к вашей базе кода и нанесете ущерб основной функции системы, вы можете навязать себе изоляцию. Это сильно отличается от системы, моделируемой для изолированной разработки. DVCS нет. Ваше понимание рабочей модели DVCS просто неверно.
Philododad
1
@philosodad: Я думаю, что начинаю понимать все лучше и лучше: каждый может получить ваш беспорядок, как в CVCS, но это больше не ваша вина, потому что вы не давили на них. :-)
Барт ван Инген Шенау
Ну ... вроде. Но, как правило, Алиса сначала клонирует или разветвляет, а затем объединяет ваши изменения, что упрощает вид, будто она никогда не видела ваш ошибочный код!
Philododad