Различие между МЕРЗАВЦЕМ и CVS

Question

Различие между МЕРЗАВЦЕМ и CVS

Как насчет:

task = BashOperator(
    task_id='switch2BMhome',
    bash_command="cd /home/pchoix/bm3 && ./bm3.py runjob -p client1 -j ingestion",
    dag=dag)

120

git version-control cvs

задан Ajay 8 August 2016 в 11:15

5 ответов

Git is a DVCS, as opposed to CVS being a centralized one. Simplistic description will be: you get all benefits of version control when you're not connected to any of multiple possible repositories, plus operations are faster.

4

ответ дан 24 November 2019 в 01:36

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

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

3

ответ дан 24 November 2019 в 01:36

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

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

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

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

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

2

ответ дан 24 November 2019 в 01:36

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

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

3

ответ дан 24 November 2019 в 01:36

Другие вопросы по тегам:

git version-control cvs

Похожие вопросы:

score 323 · Accepted Answer

Основное отличие состоит в том, что (как уже было сказано в других ответы) 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 Changelog для сообщений фиксации в 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 , публикация отделена от создания коммита, можно изменять (редактировать, переписывать) неопубликованную часть истории, не причиняя неудобств другим пользователям. В частности, если вы заметили опечатку (или другую ошибку) в сообщении о коммите или ошибку в коммите, Вы можете просто использовать "git commit --amend". Это невозможно (по крайней мере, без тяжелой хакерской атаки) в CVS.
Больше инструментов . Git предлагает гораздо больше инструментов, чем CVS. Одним из более важных является « git bisect », который можно использовать для нахождения коммита (ревизии), который привел к ошибке; если ваши коммиты небольшие и автономные, выяснить, где ошибка, довольно просто.

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

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

Если вы предпочитаете иметь линейную историю и избегать слияний, вы всегда можете использовать рабочий процесс commit-merge-Recommit через «git rebase» (и "git pull --rebase"), который похож на CVS в том смысле, что вы воспроизводите свои изменения поверх обновленного состояния. Но вы всегда делаете первый.
Нет необходимости в центральном хранилище С Git нет необходимости иметь единственное центральное место, где вы фиксируете свои изменения. Каждый разработчик может иметь свой собственный репозиторий (или лучшие репозитории: частный, в котором он / она занимается разработкой, и общедоступный, где он / он публикует ту часть, которая готова), и они могут извлекать / извлекать друг из друга репозитории, в симметричная мода. С другой стороны, для более крупного проекта характерно иметь социально определенный / назначенный центральный репозиторий, из которого все извлекают (получают изменения).

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

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

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

Для CVS наиболее распространенным решением (насколько я понимаю) для доступа только для чтения является гостевая учетная запись для протокола 'pserver' в CVS_AUTH_PORT (2401) обычно называется «анонимный» и с пустым паролем. Учетные данные по умолчанию хранятся в файле $ HOME / .cvspass , поэтому вы должны предоставить его только один раз; тем не менее, это небольшой барьер (вы должны знать имя гостевой учетной записи или обращать внимание на сообщения сервера CVS) и раздражение.
fringe developer (leaf contributor) . Одним из способов распространения ваших изменений в OSS является отправка исправлений по электронной почте . Это наиболее распространенное решение, если вы (более или менее) случайный разработчик, отправляющий одно изменение или одно исправление. КСТАТИ. отправка исправлений может осуществляться через доску обзора (система проверки исправлений) или аналогичные средства, а не только по электронной почте.

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

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

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

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

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

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

HTH (Hope That Helps)