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

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

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

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

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

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

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

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

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

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

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

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

Моя компания в настоящее время использует 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. Они находятся в основном в восьми часовых поясах от моего офиса, и даже по довольно хорошей выделенной линии между нашими офисами SUbversion выезды болезненны, но выполнимы. Большое преимущество централизованных систем заключается в том, что вы можете потенциально проверять большие двоичные файлы в нем (например, выпуски поставщиков), не делая все распределенные репозитории огромными.

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

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

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

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

• Я делю сервер с коллегой, и мы держим основное РЕПО для нашего проекта.
• Для некоторых проектов OSS, над которыми я работаю, мы создаем патчи нашей работы с Mercurial (экспорт hg), и сопровождающий проекта просто применяет их в репозитории (импорт hg)

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

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

• Параметры распределенного управления версиями
• Почему git лучше, чем Subversion

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обратите внимание, что я использовал его только на Linux, и в основном из командной строки, хотя он должен хорошо работать на других платформах, имеет GUIs, например TortoiseBZR , и много работы выполняется по интеграции с IDEs и тому подобное.

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

Использование Subversion

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

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

1-Мультисайт: если у вас есть удаленные группы, иногда вы не можете полагаться на подключение к интернету, или это недостаточно быстро и замедляет разработчиков. Тогда наличие независимого сервера, который может синхронизировать обратно (пластик реплицирует ветви туда и обратно), очень полезно и ускоряет процесс. Это, вероятно, один из самых распространенных сценариев для компаний, так как большинство из них все еще обеспокоены практикой "totally distributed", где каждый разработчик имеет свой собственный реплицированный репозиторий.

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

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

Мост git-svn немного шаткий, потому что при регистрации в SVN он переписывает все коммиты, чтобы добавить свой комментарий git-svn-id. Это разрушает приятную историю слияний между РЕПО моего коллеги и шахтой. Я предсказываю, что мы вообще не будем использовать центральный репозиторий, если каждый член команды будет использовать Git.

Вы не сказали, какую ОС вы разрабатываете, но Git имеет тот недостаток, что вы должны использовать командную строку, чтобы получить все функции. Gitk-это хороший графический интерфейс для визуализации истории слияния, но само слияние должно быть сделано вручную. Git-Gui и плагины Visual Studio еще не настолько отполированы.

Я использую darcs 2.1.0, и он отлично подходит для моих проектов. Простой в использовании. Любовь к сбору вишни меняется.