Какие ваши любимые системы контроля версий? [закрыто]

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

Итак, что вы считаете лучшей системой контроля версий?

ртутный

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

Гит

Git просто фантастический, и я бы особенно рекомендовал его всем, кто работает над проектами с открытым исходным кодом: гораздо проще внести небольшое одноразовое изменение в проект на Git, особенно если он размещен на GitHub, чем когда он занимается электронной рассылка патчей с SVN.

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

Предупреждение: С этого поста я нашел Mercurial и люблю его намного лучше, чем SVN. Так что этот пост немного устарел с комментариями Pro SVN и общей анти-DVCS, но анти-мерзавцы все еще актуальны

Я фанат SVN над Git.

Зачем? Потому что SVN был намного проще для одного разработчика или небольшой команды, а git (в частности, msysgit) оставил мне неприятный вкус во рту.

Когда я проходил практику в небольшом магазине, меня познакомили с git на Windows. Я сразу заметил, сколько работы потребовалось, чтобы заставить его работать с Github. Сначала мне нужно было сгенерировать закрытый ключ ssh, вставить открытый ключ в Github, затем открыть страницу и открыть свой закрытый ключ каждый раз, когда я захотел нажать кнопку, что было очень неприятно.

И мне никогда не нравилось, что я сносил весь репозиторий. Я признаю, что я никогда не работал с чем-то огромным, но я бы боялся загрузить репозиторий KDE в Git, если весь репозиторий и его ревизии находятся на моем HD.

Затем был запутанный процесс, чтобы сделать коммит. ТМК, мне пришлось сначала «подготовить» все файлы, которые я хотел зафиксировать (что было ужасно, когда у вас было много файлов, мне потребовалось некоторое время, чтобы найти ручную команду для выполнения всех этапов), затем выполнить фиксацию, а затем перейти к главному РЕПО (почему это отдельная операция ?!).

У вас также были не очень (!) Очень полезные данные коммитов. О, смотри, это коммит 14f74433245ae17aeeaa часть дерева 2167a4934d0a4a7db0de и родительский d7042abb4821d3faf600. Черт, это значит? Я должен быть в состоянии понять вещи довольно быстро и не должен обращаться к какой-то странной документации.

Говоря о документации, по крайней мере, когда я ее использовал, казалось, что все было в формате файла linux man, IE смущает и бесполезен для меня. Я редко мог найти большую помощь в документах и ​​просто прибегал к Google.

Что касается коммитов, то единственное, что мне не понравилось, это отсутствие номеров версий. Теперь я знаю, что это из-за дизайна git, но любому программному обеспечению нужен номер версии. Я до сих пор помню маркерные коммиты, которые выскакивали со словами «Изменена версия на 1.8.6» или что-то подобное, но вы все равно не могли сделать числа сборки. Для меня наличие версии 1.8.6.5164 (последняя часть - номер редакции) говорит мне гораздо больше, чем просто 1.8.6, и заметка о том, что что-то незначительное изменилось, попробуйте

Что касается программного обеспечения, то основной программой для Windows является msysgit, ужасный интерфейс. Он несколько раз зависал от меня, имел ужасный интерфейс, и интеграция CLI-GUI была в лучшем случае сомнительной. Наркоманы из командной строки вокруг меня ненавидели графический интерфейс еще больше.

Теперь давайте посмотрим на SVN. И так как я на Windows и имею учетную запись Google, в частности TortoiseSVN и Google Code.

Во-первых, полная интеграция с оболочкой, чтобы сделать все в хранилище (и для вас, пользователей Linux, RabbitVCS делает то же самое), основной графический интерфейс не требуется. Получить репозиторий легко, как извлечение, SSH не нужен (не помню, если Github требовался SSH для пуллов), и нет всего репо + все прошлые коммиты сидя на вашем HD.

Фиксация очень проста, в основном потому, что не требуется SSH или подготовка. Вы просто проверяете все нужные файлы, используя очень полезную опцию select all, которая в моей версии msysgit была недоступна, вводите сообщение коммита и нажимаете commit. Затем Google Code запрашивает вашу регистрационную информацию (которую хранит большинство клиентов) и готово. Просто, легко и без SSH

Номера версий? С помощью некоторого простого кода вы можете добавить номер версии и номер фиксации ко всем извлечениям, что значительно упрощает процесс. Вы также получаете полезные номера версий, которые действительно показывают изменения, например, 1.8.6.5165 новее, чем 1.8.6.5164.

Документация? Ну, сложно сказать. Черепаха задокументирована, но я не обращался к официальной документации так долго, что не могу судить. Чтения простого вступительного руководства мне было достаточно.

Слияние - это то, что я не могу сравнить. Мне приходилось делать это один раз в Git, когда кто-то еще вносил изменения в файл, над которым я работал, но никогда в SVN.

Какой из них я бы порекомендовал? Хорошо в больших командах, у git есть свои преимущества, главным образом, в нелинейном цикле разработки. В другом проекте я видел, как 4 программиста запускались в отдельных ветвях, а затем сливали весь код очень странным образом, который каким-то образом трансформировался в конечную главную ветку. У Github и msysgit был действительно хороший инструмент визуализации для всего проекта, который мне очень понравился.

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

Следующая цитата из Q4TD в значительной степени подводит итог для меня:

«Я любил Git, пока не попробовал. Теперь я люблю Mercurial.

        - Tor Norbye, Подкаст Java Posse

Кроме того, hgsubversion делает довольно хороший клиент Subversion для Linux (где я обычно использую командную строку, в отличие от Windows, где я обычно использую TortoiseSVN). Самое большое преимущество: нет .svnподпапок в каждой папке, только .hgна верхнем уровне.

Обновление: В ответ на просьбу Алекса в комментариях «рассказать больше о том, почему git не работает для вас, и как Mercurial работал лучше»:

Я бы не сказал, что Git не работает для меня, но Murcurial работает лучше IMO.

Короче говоря, это Mercurial:

а это Git:

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

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

Ба, теперь посмотри, что ты наделал? Там повсюду разглагольствования. Двигайся, ничего не видно ... нечего видеть ...

Обновление 2: И еще один твит, о котором я только что узнал:

«Git становится легче, когда вы понимаете, что ветви - это гомеоморфные эндофункторы, отображающие подмногообразия гильбертова пространства».

У меня нет единой «лучшей» системы контроля версий, а есть единственная лучшая парадигма VCS.

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

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

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

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

Fossil - это распределенный контроль версий, отслеживание ошибок и вики-проект, построенный на базе данных SQLite в качестве хранилища.

Team Foundation Server

Потому что:

1. Это хороший, солидный VCS . (Я бы не стал считать это лучшим, но у него есть приятные дополнения.)
2. Его встроенное отслеживание задач и ошибок, которое интегрируется в Visual Studio, помогает мне оставаться сосредоточенным и знать, что мне нужно для работы со всеми в одном месте (автоматическое применение проверки к ошибке или задаче и ее закрытие довольно хорошо, хотя вы можете получите плагины для других систем / eclipse / etc, чтобы сделать это.)
3. Он интегрирует задачи / отслеживание ошибок / проекты непосредственно в Project Server, поэтому мне редко приходится обновлять планы проектов или расписания. Обновления для Project в Project Server автоматически фильтруются как задачи в TFS и в Visual Studio, чтобы я мог их видеть автоматически.

За свою долгую историю я использовал множество систем контроля версий:

• RPPT - (рулоны перфорированной бумажной ленты). В обувной коробке. Я не шучу.
• PVCS - (Система контроля версий Polytron). Первый настоящий VCS, который я использовал.
• SCCS - так давно, я не помню ничего исключительно хорошего или плохого в этом.
• RCS - как уже отмечали другие, скорее будет сосать потные ослиные яйца.
• CVS - это было только боль при использовании более чем с 2 программистами. лучшая особенность: rcs2cvs.
• VSS - он работает, кроме как во вторник, когда он повреждает весь ваш репозиторий.
• Perforce - стоит дороже, чем моя машина. Сама VCS приемлема, но глупые ИТ-специалисты, которые контролируют каждый аспект ее использования, никогда не попадут в мой «предпочтительный» список.
• SVN - ветвление и слияние это сука, но в целом это лучше, чем любой из предыдущих. Не так хорошо с большим количеством крошечных выдающихся изменений, ожидающих рассмотрения.
• Mercurial - какой маленький опыт у меня есть с этим, мне нравится. Я мог бы попробовать это на моем следующем проекте.
• Git - никогда не было возможности его использовать.

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

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

• распределенный или местный
• маленькая команда или большая
• хостинг vcs сервис или нет
• простая интеграция в другие инструменты

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

Одна из более новых систем, которую мы используем в моем офисе, это Plastic SCM (http://www.plasticscm.com/). Это очень хорошо работает для нашей небольшой команды и дает нам отличный контроль над каждым аспектом управления исходным кодом.

SCCS .

Или, если вы случайно не жили в пещере последние 38 лет, CSSC .

Серьезно, моя компания использует TeamWare , которая является своего рода псевдо-DVCS на основе SCCS.

Нет, я не шучу.

Sun перешла на Mercurial из TeamWare всего несколько лет назад. Теперь вы должны понять, почему Java, казалось, двигался так медленно.

MPW: Ну, я не могу дать ему обзор, несмотря на мои усилия.

Это было еще тогда, когда я изучал программирование в старшей школе, и единственным действительно бесплатным компилятором C ++ был Macintosh Programming Workbench, который я держал на zip-диске и вставлял в любой доступный Performa в лаборатории.

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

Это была моя первая кисть с ВК, и последняя на долгое время. Теперь я использую Git для всего.

RCS - Ревизионная система управления

Индивидуальное кодирование сделано так просто.

Не ClearCase, по крайней мере для системы Unix / Linux (возможно, с Windows, установщик проще). Мне было легче освоить новый инструмент Perforce, чем обновлять наш сервер ClearCase.

В настоящее время я использую Perforce на работе, и мне это нравится, но я понятия не имею, является ли он лучшим. Настроить среду командной строки и сервер Perforce немного неудобно, но использовать Visual Client довольно просто. Мне нравится думать, что пользователям довольно легко справляться с повседневными задачами; это просто начальная настройка требует некоторой работы.

Я использовал Visual SourceSafe и ненавидел его, но это было лучше, чем ничего, но ненамного. Последние пару лет использовал что-то под названием QCVS от Qumasoft.com, написанное, принадлежащее и поддерживаемое программистом Джимом Ворисом. Простой графический интерфейс, дешевая цена, хорошая поддержка.

Просто делает работу.