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

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

Using Subversion

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Моя компания в настоящее время использует 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 настолько прост и элегантен, что мы будем его придерживаться.

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

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

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

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

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

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

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

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

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

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

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

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

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