Используете ли вы распределенный контроль версий?

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

я имею мышление, что наши инструменты никогда не должны мешать фактической работе; они должны сделать работу легче. Так, после нескольких голов, загоняющих события, я взял на поруки. Я советовал бы делать некоторые действительно выносливые тесты с Вашей командой прежде, чем раскачивать лодку, потому что модель очень отличается, чем, к чему, вероятно, приучено большинство devs в мире SCM.

Используя Подрывную деятельность

Подрывная деятельность не распределяется, так, чтобы заставил меня думать, что мне нужна ссылка Википедии в случае, если люди не уверены, о чем я говорю:)

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

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

bzr также имеет большой плагин ( bzr-svn) разрешение Вам работать с репозиторием подрывной деятельности. Можно сделать копию svn repo (который первоначально требует времени, поскольку он выбирает всю историю для локального repo). Можно тогда сделать ответвления для различных функций. Если Вы хотите сделать быстрое исправление к соединительной линии, в то время как половина пути через Вашу функцию, можно сделать дополнительное ответвление, работу в этом, и затем объединяться назад для транкинга, оставив половину сделанной функции нетронутой и за пределами соединительной линии. Замечательный. Работа против подрывной деятельности была моим основным использованием до сих пор.

Примечание я только использовал его на Linux, и главным образом из командной строки, хотя это предназначено для работы хорошо над другими платформами, имеет графический интерфейсы пользователя такой как , TortoiseBZR и большая работа делаются на интеграции с IDE и т.п..

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

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

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

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

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

Используя Подрывную деятельность с SourceForge и другими серверами по многим различным соединениям с командами среднего размера и это работает очень хорошо.

Я personnaly использую Подвижную систему управления исходным кодом. Я использовал его некоторое время больше чем год прямо сейчас. Это был на самом деле мой первый опыт с VSC.

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

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

• я совместно использую сервер с коллегой, и мы сохраняем основной repo для нашего проекта.
• Для некоторого проекта OSS я продолжаю работать, мы создаем патчи нашей работы с Подвижным (hg экспорт), и maintener проекта просто применяют их на репозиторий (hg импорт)

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

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

• Распределенные опции управления исходным кодом
• , Почему мерзавец лучше, чем Подрывная деятельность

В месте, где я работаю, мы решили переместиться от SVN до Базара (после оценки мерзавца и подвижный). Базар был легок начаться с простыми командами (не как 140 команд, которые мерзавец имеет)

преимущества, которые мы видим, способность создать локальные ответвления и работу над ним, не нарушая основную версию. Также способность работать без доступа к сети, делая diffs быстрее.

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

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

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

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

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

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

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

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

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

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

Моя компания в настоящее время использует Подрывную деятельность, CVS, Подвижный и мерзавец.

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

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

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

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

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

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

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

Использование darcs 2.1.0 и его великое для моих проектов. Простой в использовании. Любите избирательно подходить к выбору изменений.

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

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

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

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

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

Мы используем распределенный контроль версий ( Plastic SCM ) как для многосайтовых, так и для отключенных сценариев.

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

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

I use Git at work, together with one of my coworkers. The main repository is SVN, though. We often have to switch workstations and Git makes it very easy to just pull changes from a local repository on another machine. When we're working as a team on the same feature, merging our work is effortless.

The git-svn bridge is a little wonky, because when checking into SVN it rewrites all the commits to add its git-svn-id comment. This destroys the nice history of merges between my coworker's repo an mine. I predict that we wouldn't use a central repository at all if every teammember would be using Git.

You didn't say what os you develop on, but Git has the disadvantage that you have to use the command line to get all the features. Gitk is a nice gui for visualizing the merge history, but the merging itself has to be done manually. Git-Gui and the Visual Studio plugins are not that polished yet.

Я играю с Mercurial для моих домашних проектов. Пока что мне нравится это то, что я могу иметь несколько репозиториев. Если я возьму свой ноутбук в салон, у меня все равно будет контроль версий, в отличие от того, когда я запускал CVS дома. Разветвление так же просто, как рт.ст. клон и работа над клоном.