Каковы преимущества систем контроля версий, которые версии каждого файла в отдельности?

15

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

Некоторые системы контроля версий для каждого файла:

  • CVS
  • ClearCase
  • Visual SourceSafe

Некоторые системы управления версиями с полным хранилищем:

  • SVN
  • Гит
  • ртутный

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

Каковы преимущества этих файловых систем контроля версий? Какие проблемы существуют у систем контроля версий «всего хранилища», которых нет у систем контроля версий для каждого файла?

version-control Майк Дэниелс
источник
3
Я думаю, что в основном это просто исторически так, и мы сейчас переходим от файлово-ориентированных систем к ориентированным на наборы изменений, но с сегодняшней точки зрения трудно понять, почему люди даже попробовали индивидуальный подход. Отличный вопрос!
blubb
Извиняюсь, если этот вопрос звучит как аргумент. Это продукт недавнего разочарования.
Майк Дэниелс
1
@ Майк Дэниелс: Это не так (по крайней мере для меня), так как вы явно просите преимущества.
blubb
Эти две точки зрения - просто разные соглашения. Любой аргумент в пользу одного над другим только вызывает контраргумент у сторонников другой стороны. Например, если вы хотите, чтобы в Clearcase было «целое повторение», вы можете настроить свою конфигурационную спецификацию по дате.
Mouviciel
У SVN есть версия для файла, или это изменилось также в последней версии?
Klaim

Ответы:

12

По моему опыту, их нет: VCS с "полным хранилищем" строго доминирует над VCS "на файл".

Рейн Хенрикс
источник
3

Каждый файл имеет преимущество, когда вы строите линейки продуктов (несколько программных продуктов) из одного и того же хранилища.

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

И это не случайный пример, который я вытащил из воздуха.

Это произошло в прошлый раз, когда я отправлял обновления программного обеспечения в армию США для системы, которую они приобрели в большом количестве у моего предыдущего работодателя. Долларовая стоимость контрактов измерялась долями в миллиарды долларов (тогда, когда доллары США стоили намного больше)

Так что это помогает несколько раз.

Как ни странно: там, где я сейчас работаю, мы отправляем каждому клиенту также разные материалы ... (И это не то, что я решил, если вам интересно).

Я подозреваю, что это гораздо чаще встречается в оборонном / аэрокосмическом пространстве, чем в термоусадочной пленке или веб-приложениях.

Тим Виллискрофт
источник
3
Но ветвь целого хранилища файлов также будет отвечать тем же требованиям. Например, в bzr ветви полностью независимы от магистрали до вашего слияния (или совместного использования репозитория).
edA-qa mort-ora-y
1
Я не могу вспомнить ни одной ситуации, когда ветвление в системе «весь репозиторий» не могло бы лучше выразить требуемое состояние, чем полагаться на состояние, внешнее по отношению к VCS, чтобы определить, какие файлы использовать в VCS «на файл». Моя первая работа после универа использовала RCS, набор сценариев для версии проекта и сценарий верхнего уровня для версии сценариев версий - настоящий кошмар, и да, это тоже было для военного проекта. * 8 ')
Марк Бут
@ Марк Бут, клиент знал, какие файлы были изменены и какие исправления они хотели. Итак, аудит физической конфигурации проводился по номеру контроля версий
Тим Виллискрофт,
Я говорю, что версия + проверенный патч требует разной информации в разных местах, VCS и аудиторах. В случае ветвления в системе «весь репозиторий» эти два состояния записываются как отдельные объекты. Теперь та же информация дублируется между VCS и системой аудита и должна всегда совпадать. gitВы можете даже различать автора и коммиттера, так что вы можете хранить «проверенный» репозиторий, в котором вы знаете как создателя патча (автора), так и аудитора (коммиттера). Предоставьте нам примерную ситуацию, и я переверну свою -1.
Марк Бут
@ Марк стенд какие патчи? они знали, что их программное обеспечение было этим набором файлов A 1.01 B 1.05 D 1.55 E 1.44 F 1.01 и SVD для версии, которую они принимали, имели информацию об изменении файла за файлом, например, E был изменен, чтобы исправить дефект 1104, старая версия 1.43, новая версия 1.44 , Боже, помоги нам, если бы мы изменили F с версии 1.01. Ситуация была еще более сложной, потому что были исправлены ошибки, для которых они не хотели изменений. Эти люди хотели минимального набора изменений, чтобы поднять только некоторые особенности, выбранные в течение года разработки. Выборочный исправление ошибок.
Тим Уиллискрофт
3

Нет никакого преимущества для управления версиями каждого файла.

Эти недостатки , с другой стороны, многочисленны и проявляются.

Уильям Пейн
источник
0

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

Арвинд Чинния
источник
0

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

В некоторых особых случаях - / etc или. файлы в вашем домашнем каталоге в Unix - единственные, которые у меня обычно есть - вы обрабатываете (в основном) несвязанные файлы. И тогда наличие системы, которая настаивает на синхронизации несвязанных изменений, может быть неприятным.

AProgrammer
источник