it-swarm.com.ru

Разница между GIT и CVS

В чем разница между системами контроля версий Git и CVS?

Я счастливо использую CVS уже более 10 лет, и теперь мне сказали, что Git намного лучше. Может кто-нибудь объяснить, в чем разница между ними, и почему один лучше, чем другой?

114
jay

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

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

  • Настройка хранилища . Git хранит репозиторий в каталоге .git в верхнем каталоге вашего проекта; CVS требует настройки CVSROOT, центральное место для хранения информации контроля версий для различных проектов (модулей). Следствием этого дизайна для пользователя является то, что импортировать существующие источники в систему управления версиями так же просто, как "git init && git add. && git commit" в Git, в то время как это более сложный в CVS.

  • Атомные операции . Поскольку CVS в начале был набором скриптов для системы контроля версий RCS для каждого файла, коммиты (и другие операции) не являются атомарными в CVS; если операция с хранилищем прерывается в середине, хранилище может остаться в несогласованном состоянии. В Git все операции являются атомарными: либо они завершаются успешно, либо завершаются неудачей без каких-либо изменений.

  • Изменения . Изменения в CVS относятся к каждому файлу, тогда как изменения (коммиты) в Git всегда относятся ко всему проекту. Это очень важно смена парадигмы. Одним из последствий этого является то, что в Git очень легко отменить (создать изменение, которое отменяет) или отменить целое изменение; Другое последствие заключается в том, что в CVS легко делать частичные проверки, в то время как в Git это практически невозможно. Тот факт, что изменения для каждого файла сгруппированы вместе, привел к созданию GNU формата журнала изменений для сообщений фиксации в CVS; Пользователи Git используют (и некоторые инструменты Git ожидают) другое соглашение: в одной строке описывается (обобщение) изменений, за ними следует пустая строка, за которой следует более подробное описание изменений.

  • Именование редакций/номеров версий . Есть еще одна проблема, связанная с тем, что в CVS изменения происходят по файлам: номера версий (как вы можете иногда видеть в расширение ключевого слова, см. Ниже), например 1.4, показывают, сколько раз данный файл был изменен. В Git каждая версия проекта в целом (каждый коммит) имеет свое уникальное имя, заданное идентификатором SHA-1; обычно первых 7-8 символов достаточно для идентификации коммита (вы не можете использовать простую схему нумерации версий в распределенной системе контроля версий - для этого требуются центральные права нумерации). В CVS для того, чтобы иметь номер версии или символическое имя, относящееся к состоянию проекта в целом, вы используете теги ; то же самое верно и в Git, если вы хотите использовать имя типа 'v1.5.6-rc2' для какой-то версии проекта ... но теги в Git намного проще в использовании.

  • Легкое ветвление . Филиалы в CVS, на мой взгляд, слишком сложны, и с ними трудно иметь дело. Вы должны пометить ветви, чтобы иметь имя для всей ветви репозитория (и даже в некоторых случаях, если я правильно помню, может произойти сбой из-за обработки каждого файла). Добавьте к этому тот факт, что CVS не имеет отслеживание слияния, поэтому вы должны либо помнить, либо вручную отмечать точки слияния и точки ветвления и вручную предоставлять правильную информацию для слияния "cvs update -j" для слияния ветки, и это делает ветвление ненужным и сложным в использовании. В Git создавать и объединять ветки очень легко; Git запоминает всю необходимую информацию сама по себе (поэтому объединить ветку так же просто, как "git merge branchname") ... это нужно было, потому что распределенная разработка естественным образом ведет к нескольким ветвям.

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

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

    • при проверке указанного коммита вы получите информацию о том, что какой-то файл был переименован,
    • правильное объединение учитывает переименования (например, если файл был переименован только в одной ветви)
    • "git blame", (лучше) эквивалент "cvs annotate", инструмента для показа истории содержимого файла по строкам, может следовать за движением кода также при переименовании
  • Двоичные файлы . CVS имеет очень ограниченную поддержку бинарных файлов (например, изображений), требуя от пользователей явной пометки бинарных файлов при добавлении (или позже, используя "cvs admin" или через обертки, чтобы сделать это автоматически на основе имени файла), чтобы избежать искажения двоичный файл с помощью преобразования конца строки и расширения ключевого слова. Git автоматически обнаруживает двоичный файл на основе содержимого так же, как это делают CNU diff и другие инструменты; Вы можете переопределить это обнаружение, используя механизм gitattributes. Более того, двоичные файлы защищены от невосстановимого искажения благодаря значению по умолчанию для safecrlf (и тому факту, что вам нужно запросить преобразование в конце строки, хотя это может быть включено по умолчанию в зависимости от распределения), а также этому ключевому слову (ограниченному) расширение - это строгое согласие в Git.

  • Расширение ключевого слова . Git предлагает очень, очень ограниченный набор ключевых слов по сравнению с CVS (по умолчанию). Это связано с двумя фактами: изменения в Git относятся к репозиторию, а не к файлу, и Git избегает изменения файлов, которые не изменились при переключении на другую ветку или перемотке на другую точку истории. Если вы хотите встроить номер редакции с помощью Git, вы должны сделать это с помощью вашей системы сборки, например, следующий пример сценария GIT-VERSION-GEN в исходных кодах ядра Linux и в исходных текстах Git.

  • Исправление коммитов . Поскольку в распределенных VCS, таких как Git act of publishing, отдельно от создания коммита, можно изменять (редактировать, переписывать) неопубликованную часть истории, не причиняя неудобств другим пользователям. В частности, если вы заметили опечатку (или другую ошибку) в сообщении коммита или ошибку в коммите, вы можете просто использовать "git commit --amend". Это невозможно (по крайней мере, без тяжелой хакерской атаки) в CVS.

  • Дополнительные инструменты . Git предлагает гораздо больше инструментов, чем CVS. Одним из наиболее важных является " git bisect ", который можно использовать для нахождения коммита (ревизии), который привел к ошибке; если ваши коммиты малы и самодостаточны, выяснить, где ошибка, будет довольно легко.


Если вы сотрудничаете хотя бы с одним другим разработчиком, вы также найдете следующие различия между Git и CVS:

  • Коммит до слияния Git использует commit-before-merge, а не, как CVS, merge-before-commit (или pdate-then-commit). Если, когда вы редактировали файлы, готовясь к созданию нового коммита (новой ревизии), кто-то другой создал новый коммит в той же ветке, и теперь он находится в репозитории, CVS вынуждает вас сначала обновить ваш рабочий каталог и разрешить конфликты, прежде чем разрешить вам коммит. Это не относится к Git. Сначала вы фиксируете, сохраняя свое состояние в управлении версиями, затем объединяете другие изменения разработчика. Вы также можете попросить другого разработчика выполнить слияние и разрешить конфликты.

    Если вы предпочитаете иметь линейную историю и избегать слияний, вы всегда можете использовать commit-merge-Recommit ​​рабочий процесс через "git rebase" (и "git pull --rebase"), который похож на CVS в что вы воспроизводите свои изменения поверх обновленного состояния. Но вы всегда делаете первый.

  • Нет необходимости в центральном хранилище В Git нет необходимости иметь единственное центральное место, где вы фиксируете свои изменения. Каждый разработчик может иметь свой собственный репозиторий (или лучший репозиторий: частный, в котором он/она занимается разработкой, и общедоступный, где он/он публикует ту часть, которая готова), и они могут извлекать/извлекать друг из друга репозитории, в симметричная мода. С другой стороны, для более крупного проекта характерно иметь социально определенный/назначенный центральный репозиторий, из которого все извлекают (получают изменения).


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

  • Lurker . Если вы заинтересованы только в получении последних изменений из проекта, ( не распространяйте свои изменения ) или занимайтесь private разработка (без участия в оригинальных проектах); или вы используете иностранные проекты в качестве основы вашего собственного проекта (изменения являются локальными и нет смысла их публиковать).

    Git поддерживает здесь анонимный неаутентифицированный доступ только для чтения через настраиваемый эффективный git://protocol или если вы находитесь за блокировкой брандмауэра DEFAULT_GIT_PORT (9418) Вы можете использовать простой HTTP.

    Для CVS наиболее распространенным решением (насколько я понимаю) для доступа только для чтения является guest account ​​ для протокола 'pserver' на CVS_AUTH_PORT (2401), обычно называемый "анонимным" и с пустым паролем. Учетные данные хранятся по умолчанию в файле $HOME/.cvspass, поэтому вы должны предоставить его только один раз; тем не менее, это немного препятствие (вы должны знать имя гостевой учетной записи или обращать внимание на сообщения сервера CVS) и раздражение.

  • крайний разработчик (автор листьев) . Один из способов распространения ваших изменений в OSS - это отправка исправлений по электронной почте . Это наиболее распространенное решение, если вы (более или менее) случайный разработчик, отправляющее одно изменение или исправляющее одно исправление. КСТАТИ. отправка исправлений может осуществляться через доску обзора (система проверки исправлений) или аналогичными способами, а не только по электронной почте.

    Git предлагает здесь инструменты, которые помогают в этом механизме распространения (публикации) как для отправителя (клиента), так и для сопровождающего (сервера). Для людей, которые хотят отправить свои изменения по электронной почте, есть инструмент " git rebase " (или "git pull --rebase"), чтобы воспроизвести ваши собственные изменения поверх текущей версии, поэтому ваши изменения включены начало текущей версии (свежее) и " git format-patch " для создания электронного письма с сообщением о коммите (и авторством), изменения в форме (расширенного) унифицированного формата diff (плюс diffstat для более простого) обзор). Сопровождающий может превратить такую ​​электронную почту непосредственно в коммит, сохраняя всю информацию (включая сообщение о коммите), используя " git am ".

    CVS не предлагает таких инструментов: вы можете использовать "cvs diff"/"cvs rdiff" для генерации изменений и использовать патч GNU для применения изменений, но, насколько я знаю, нет способа автоматизировать применение фиксации сообщение. CVS предназначался для использования в клиентском <-> серверном стиле ...

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

    Это решение относится к распределенным системам контроля версий, поэтому, конечно, CVS не поддерживает такой способ сотрудничества. Существует даже инструмент под названием "git request-pull", который помогает подготовить электронную почту для отправки сопровождающему с запросом на получение из вашего хранилища. Благодаря "git bundle" вы можете использовать этот механизм, даже не имея публичного репозитория, отправляя пакет изменений по электронной почте или через sneakernet. Некоторые сайты хостинга Git, такие как GitHub , имеют поддержку для уведомления о том, что кто-то работает (опубликовал какую-то работу) над вашим проектом (при условии, что он/она использует тот же сайт хостинга Git), и для PM-публикации вид запроса тяги.

  • главный разработчик , т.е. тот, кто напрямую публикует свои изменения (в основной/канонический репозиторий). Эта категория шире для распределенных систем управления версиями, поскольку наличие нескольких разработчиков с доступом для записи к центральному репозиторию является не только возможным рабочим процессом (у вас может быть один сопровождающий, который pushes изменения в каноническом репозитории, наборе лейтенантов/сопровождающих подсистем, из которых он/она извлекает, и широкий круг конечных разработчиков, которые отправляют исправления по почте либо в список рассылки сопровождающего/проекта, либо в один из лейтенанты/submaintainers).

    С Git у вас есть выбор использования протокола SSH (протокол git, заключенный в SSH) для публикации изменений с помощью таких инструментов, как "git Shell" (для обеспечения безопасности , ограничивая доступ к учетным записям Shell) или Gitosis (для управления доступом, не требуя отдельных учетных записей Shell), и HTTPS с помощью WebDAV, с обычной HTTP-аутентификацией.

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

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

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

HTH (Надеюсь, что поможет)

316
Jakub Narębski

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

4
Anton Gogolev

веб-сайт Git это объясняет, наверное, лучше всего.

Моя любимая особенность - это возможность делать коммиты в автономном режиме. И скорость, абсолютная скорость, с которой происходит все, кроме толкания и вытягивания. (И эти операции по своей природе неразрушающие, поэтому вы можете нажимать/вытягивать, когда вы берете кофе, если ваш центральный репозиторий отстает.) Еще одна приятная вещь - это то, что в него входят батареи: встроенный gitk - достаточно хороший просмотрщик истории; git gui - достаточно хороший инструмент коммита; с выходной окраской git add -i, git add -p, git rebase -i являются достаточно хорошими интерактивными интерфейсами; git daemon и git instaweb достаточно хороши для совместной работы, если вы не хотите/не можете возиться со своим центральным репо.

3
millimoose

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

Несколько вещей, которые делают cvs более приятным, чем он мог бы быть, - это cvsps, а другая - это либо патчи Эндрю Мортона, либо лоскутное одеяло. Cvsps позволяет вам преобразовывать несколько файлов коммита в один патч (и, таким образом, извлекать "наборы изменений" из CVS) во время квилтинга, или сценарии патчей Эндрю Мортона позволяют довольно легко и удобно вносить в cvs разумные "наборы изменений", позволяя вам работать над несколькими вещами одновременно, сохраняя их разделенными до совершения. У CVS есть свои причуды, но я привык к большинству из них.

3
smcameron

"счастливо использовать CVS более x лет", это интересная идея :-) Это огромный шаг вперед по сравнению с хранением большого количества копий, но ...

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

Люди в вашей организации привыкли к ограничениям в cvs, и ваши рабочие методы соответствующим образом адаптировались;

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

Основной принцип: чем сложнее что-то, тем меньше людей это делают.

2
Chris Huang-Leaver