Используете ли вы распределенный контроль версий? - PullRequest
37 голосов
/ 26 августа 2008

Я хотел бы услышать от людей, которые используют распределенный контроль версий (он же распределенный контроль версий, децентрализованный контроль версий) и как они его находят. Что вы используете, Mercurial, Darcs, Git, Bazaar? Вы все еще используете это? Если в прошлом вы использовали клиент-серверные rcs, вы находите это лучше, хуже или просто другим? Что ты можешь сказать мне, что заставит меня запрыгнуть на подножку? Или спрыгните в этом отношении, мне было бы интересно услышать от людей с отрицательным опытом также.

В настоящее время я смотрю на замену нашей текущей системы контроля версий (Subversion), которая является стимулом для этого вопроса.

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

Если вы не уверены, что такое распределенное управление версиями, вот пара статей:

Введение в управление распределенной версией

Запись в Википедии

Ответы [ 18 ]

30 голосов
/ 26 августа 2008

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

  1. Локальный контроль версий. Иногда я работаю над чем-то и хочу сохранить историю версий, но я не готов отправить ее в центральные репозитории. С распределенной VCS я могу просто зафиксировать свое локальное репо, пока оно не будет готово, без ветвления. Таким образом, если другие люди вносят изменения, которые мне нужны, я все равно могу их получить и интегрировать в свой код. Когда я буду готов, я отправлю его на сервер.
  2. Меньше конфликтов слияния. Они все еще случаются, но они кажутся менее частыми и представляют меньший риск, потому что весь код регистрируется в моем локальном репо, так что даже если я испорчу слияние, я всегда могу сделать резервную копию и сделать это снова.
  3. Разделяйте репо как ветви. Если у меня одновременно работает пара векторов разработки, я могу просто сделать несколько клонов своего репо и разработать каждую функцию независимо. Таким образом, если что-то сломается или поскользнется, мне не придется вытаскивать куски. Когда они будут готовы уйти, я просто объединю их.
  4. Скорость. С Mercurial работать гораздо быстрее, в основном потому, что большинство ваших общих операций выполняются локально.

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

6 голосов
/ 27 августа 2008

На том месте, где я работаю, мы решили перейти с SVN на базар (после оценки мерзавца и меркуриала). Bazaar было легко начать с простых команд (не так, как у 140 команд, которые есть в git)

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

Одна команда в bzr, которая мне нравится, это расширение полки. Если вы начинаете работать с двумя логически разными частями кода в одном файле и хотите зафиксировать только один фрагмент, вы можете использовать расширение полки, чтобы буквально отложить другие изменения позже. В Git вы можете сделать то же самое с игрой в индексе (промежуточной области), но bzr имеет лучший интерфейс для этого.

Большинство людей неохотно переходили, поскольку им приходилось вводить две команды для фиксации и нажатия (bzr ci + bzr push). Также им было трудно понять концепцию ветвей и слияний (никто не использует ветки и не объединяет их в SVN).

Как только вы это поймете, это увеличит производительность разработчика. Пока все не поймут, что среди всех будет противоречивое поведение.

5 голосов
/ 26 августа 2008

На моем рабочем месте мы перешли на Git из CVS около двух месяцев назад (большая часть моего опыта связана с Subversion). Хотя ознакомление с распределенной системой было связано с обучением, я обнаружил, что Git превосходит две ключевые области: гибкость рабочей среды и слияние.

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

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

5 голосов
/ 04 октября 2008

В настоящее время моя компания использует Subversion, CVS, Mercurial и git.

Когда мы начинали пять лет назад, мы выбрали CVS, и мы до сих пор используем его в моем подразделении для нашей основной ветки разработки и поддержки релизов. Тем не менее, многие из наших разработчиков используют Mercurial по отдельности как способ иметь частные контрольные точки без проблем с ветвями CVS (и особенно с их слиянием), и мы начинаем использовать Mercurial для некоторых ветвей, в которых работает до 5 человек. Есть хороший шанс, что мы, наконец, откажемся от CVS через год. Наше использование Mercurial выросло органически; некоторые люди до сих пор даже не трогают его, потому что им нравится CVS. Все, кто пробовал Mercurial, в конечном итоге были довольны им, без особой кривой обучения.

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

Самым большим препятствием является то, что вам нужно перенастроить мозги разработчиков и менеджеров, чтобы они ушли от единой линейной модели ветвления. Лучшее лекарство для этого - доза Линуса Торвальдса, сообщающая вам, что вы глупы и уродливы , если вы используете централизованный SCM. Хорошие инструменты визуализации истории помогли бы, но я еще не удовлетворен тем, что доступно.

Mercurial и CVS хорошо работают для нас с разработчиками, использующими сочетание Windows, Linux и Solaris, и я не заметил никаких проблем с часовыми поясами. (Действительно, это не так уж сложно; вы просто используете секунды эпохи внутри, и я ожидаю, что все основные системы SCM получат это право).

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

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

Мы используем git для работы с ядром Linux. Git будет более подходящим для нас, когда родная версия Windows станет зрелой, но я думаю, что дизайн Mercurial настолько прост и элегантен, что мы будем придерживаться его.

4 голосов
/ 26 августа 2008

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

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

У меня есть 2 способа поделиться своим кодом с людьми:

  • Я делю сервер с коллегой, и у нас есть основной репозиторий для нашего проекта.
  • Для какого-то проекта OSS, над которым я работаю, мы создаем исправления нашей работы с Mercurial (hg export), а специалист по обслуживанию проекта просто применяет их в хранилище (hg import)

С ним действительно легко работать, но он очень мощный. Но, как правило, выбор VSC действительно зависит от потребностей нашего проекта ...

4 голосов
/ 26 августа 2008

Я не пользуюсь распределенным управлением исходным кодом, но, возможно, эти вопросы и ответы помогут вам понять:

3 голосов
/ 28 ноября 2008

Использовали дарки в большом проекте (GHC) и для множества маленьких проектов. У меня отношения любви / ненависти с дарками.

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

Минусы: нет понятия истории - вы не можете восстановить «положение вещей 5 августа». Я так и не понял, как использовать дарки, чтобы вернуться к более ранней версии.

Разрушитель сделок: дарки не масштабируются. У меня (и многих других) возникли большие проблемы с GHC с использованием дарков. У меня было зависание со 100% загрузкой процессора в течение 9 дней, пытаясь вытянуть Изменения за 3 месяца. Прошлым летом у меня был плохой опыт, когда я потерял две недели пытаясь заставить функционировать даркс и в итоге прибегнуть к воспроизведению всех моих изменений вручную в нетронутом хранилище.

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

3 голосов
/ 26 августа 2008

Еще до того, как мы отключили рабочие станции Sun для разработки встроенных систем, мы использовали решение Sun TeamWare . TeamWare - это полностью распространяемое решение, использующее SCCS в качестве локальной системы проверки файлов репозитория, а затем упаковывающее его с помощью набора инструментов для обработки операций слияния (выполняемых посредством переименования ветвей) обратно в централизованные репозитории, которых может быть много. Фактически, поскольку он распространяется, на самом деле нет главного репозитория как такового (за исключением соглашения, если вы этого хотите), и у всех пользователей есть свои собственные копии всего исходного дерева и ревизий. Во время операций «возврата» инструмент слияния с использованием 3-way diffs алгоритмически сортирует, что к чему, и позволяет объединять изменения от разных разработчиков, накопленные с течением времени.

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

Лично я считаю, что распределенная модель, реализованная TeamWare, или гибридная модель, реализованная AccuRev, превосходит полностью централизованные решения. Основная причина этого заключается в том, что нет необходимости извлекать файл или заблокировать файл другим пользователем. Кроме того, пользователям не нужно создавать или определять ветви; инструменты делают это для вас неявно. Когда есть более крупные команды или другие команды, которые вносят вклад или поддерживают набор исходных файлов, это разрешает «сгенерированные инструментом» блокировки блокирующих коллизий и позволяет координировать изменения кода на уровне разработчика, которые в конечном итоге должны в любом случае координировать изменения. В некотором смысле распределенная модель допускает гораздо более мелкозернистую «блокировку», а не блокировку по курсу, установленную централизованными моделями.

2 голосов
/ 27 августа 2008

Моя рабочая группа использует Git, и в этом разница во всем мире. Мы использовали SCCS и кучу сценариев csh для управления довольно большими и сложными проектами, которые разделяли код между ними (в любом случае пытались).

С Git поддержка субмодулей облегчает многие вещи, и необходим только минимум сценариев. Наши усилия по разработке релизов пошли очень далеко, потому что ветки легко обслуживать и отслеживать. Возможность дешевого ветвления и слияния действительно позволяет достаточно легко поддерживать единый набор источников по нескольким проектам (контрактам), тогда как раньше любое нарушение типичного потока вещей было очень и очень дорого. Мы также обнаружили, что возможность сценариев Git имеет огромный плюс, потому что мы можем настроить его поведение с помощью хуков или сценариев, которые делают . git-sh-setup, и это не похоже на кучу кладжей, подобных до этого.

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

Отчасти это только то, что мы вышли из начала 80-х и внедрили некоторые современные механизмы контроля версий, но Git "сделал это правильно" в большинстве областей.

Я не уверен в степени ответа, который вы ищете, но наш опыт работы с Git был очень, очень положительным.

2 голосов
/ 26 августа 2008

Я действительно люблю Git, особенно с GitHub. Так приятно иметь возможность фиксировать и откатываться локально. И слияния по сбору вишни, хотя и не тривиальные, не очень сложны и гораздо более продвинуты, чем то, что могут сделать Svn или CVS.

...