Ответ 1
Основная идея управления версиями - управлять несколькими версиями одной и той же единицы информации. Идея резервного копирования - скопировать последнюю версию информации в безопасное место - более старые версии могут быть перезаписаны.
Как управление версиями отличается от обычных резервных копий?
Забудьте об украшении функций и сосредоточьтесь на душе контроля версий. Есть ли четкая строка, в которой должны выполняться резервные копии, прежде чем их можно будет назвать VCS? Или они, в глубине души, одно и то же с разными целевыми рынками?
Если существует фундаментальное различие, каково абсолютное минимальное требование для достижения статуса контроля версий?
Когда вы отвечаете, пожалуйста, не просто перечисляйте функции (например, дельта-компрессию, распределенные/центральные репозитории и решения параллельного доступа), которые имеют или должны иметь большинство систем управления версиями, если они фактически не нужны для определения VCS по определению.
Основная идея управления версиями - управлять несколькими версиями одной и той же единицы информации. Идея резервного копирования - скопировать последнюю версию информации в безопасное место - более старые версии могут быть перезаписаны.
Возможность выполнения ветвления и объединения разделяет системы управления версиями от простых резервных копий. "Несколько одновременных юниверсов".
См. также Eric Sink отлично руководство по версии/источнику.
Я вижу несколько принципиальных различий между резервными копиями и контролем версий:
Однако самое важное различие между резервными копиями и VCS заключается в том, что изменения в VCS имеют смысл. В резервной копии создается новая версия, потому что какой-то компьютер где-то решил, что это было x
часов с момента последней резервной копии; само изменение совершенно бессмысленно. В VCS создается новая версия, потому что некоторые люди решили, что эта версия имеет свой собственный смысл, свою собственную идентичность, отличную от всех других версий. Таким образом, в резервной копии все версии равны (точнее: они одинаково бессмысленны), тогда как в VCS все версии являются особыми (они имеют свои собственные уникальные значения). В VCS изменения имеют фактическую историю, где одно событие привело к другому, в резервной копии есть только цепочка несвязанных событий.
Близко к этому относится понятие метаданных изменений. В VCS каждое изменение имеет автора, отметку времени и, самое главное, сообщение фиксации. Это сообщение фиксации записывает, почему было сделано изменение, другими словами, оно записывает "значение", о котором я писал в предыдущем абзаце.
История фиксации и особенно сообщения фиксации являются наиболее важными данными в репозитории VCS, а не самим кодом! Эти метаданные полностью отсутствуют в резервной копии.
Контроль версий представляет собой всю историю изменений; резервные копии пытаются убедиться, что вы не потеряете его.
Вот несколько
Управление версиями является совместным, резервное копирование - всего лишь моментальный снимок.
Пример. С контролем версий два человека могут одновременно редактировать один и тот же файл, а система достаточно умна, чтобы объединить изменения вместе. С резервной копией, какая версия файла "выиграет?" Резервное копирование никогда не "объединяет" два разных резервных копии в одну "истинную" резервную копию.
Конечно, между ними существует серая область, однако я бы определил следующее:
Управление версиями инициируется действием "write", где, как правило, резервное копирование запускается с помощью временного интервала.
Программное обеспечение для резервного копирования может быть настроено для запуска каждую секунду, а не для хранения данных, если никаких изменений не произошло, но этого недостаточно для того, чтобы его рассматривали как контроль версий в моих глазах, так как файл можно дважды изменить в второй.
На мой взгляд, вот некоторые минимальные возможности VCS, которые могут быть не в базовой резервной копии:
В VCS должно храниться несколько версий (где в качестве резервной копии может храниться только последнее последнее хорошо известно)
Из-за 1. каждая версия должна быть идентифицирована как-то (дата, тег, идентификатор версии)
VCS может поддерживать несколько одновременных пользователей
VCS для исходного кода, как правило, поддерживает разветвление, объединение, добавление комментариев и просмотр deltas
Основное отличие, которое выделяется для меня, заключается в том, что управление версиями позволяет нескольким пользователям легко работать с одним и тем же кодом. Резервные копии этого не делают.
Я бы рассмотрел резервные копии очень простой системы управления версиями. Я бы не рекомендовал его для многих вещей, но если у меня есть небольшой script на моем домашнем компьютере, я использую датированные резервные копии вместо полнофункционального VCS. Это нормально, потому что я единственный, кто меняет файл, поэтому мне не нужно беспокоиться о конфликтах или кто внес изменения.
Контроль версий сохраняет историю изменений, и большинство систем управления версиями сохраняют разницу между двумя версиями, а не все. Резервные копии хранят все, и у них нет истории, если вы не сделаете это вручную. Обычно резервные копии неэффективны. Однако системы контроля версий не очень эффективны с двоичными файлами.
Управление версиями - это в основном автоматизированная система резервного копирования, которая позволяет нескольким пользователям вносить свой вклад. Есть больше возможностей, связанных с программным обеспечением, таким как CVS, но да, это резервная система под капотом. Это не означает, что вы должны вручную создавать резервные копии вместо использования управления версиями, хотя они находятся в одной и той же области вычислений.
Возможно, они принципиально одинаковы, пока вы не добавите слово "хорошо".
"хороший" VCS имеет метаданные, такие как описания, предоставленные пользователем
"хорошие" резервные копии распределяются географически
Я думаю, что вы можете создавать аргументы как для создания резервных копий вместе с VCS, так и для рассмотрения их как полностью отдельных. Но я думаю, что вы не можете не говорить об отдельных функциях VCS, так как это функции, которые отличает VCS от резервного решения:
В моих глазах эти функции являются определяющими. Если вы проигнорируете их, VCS будет по существу тем же самым, что и инкрементное решение для резервного копирования.
Если вы посмотрите на распределенный VCS, вы можете найти более сильное понятие отслеживания ветвей, чем в нераспределенной VCS. То есть, может быть не одна ветвь head/trunk, а несколько в любой момент времени. Что-то, что не удалось решить с помощью резервного копирования, я нашел.
Негативное минимальное требование для системы резервного копирования, чтобы она использовалась для управления версиями, - это инкрементное резервное копирование и восстановление для отдельных элементов резервного копирования. Дополнительные возможности (Collaboration, Branching, Diff Comparison) могут сделать его лучшей системой VCS, но поскольку вы можете управлять версиями, если вы можете иметь надежный доступ к извлечению и откату для поэтапно разных версий элемента, который вы создали, вы может использовать его как "VCS". Итак, я полагаю, что основное отличие системы резервного копирования и управления версиями заключается в том, что вы используете эту систему. В частности, учитывая, что вы можете, если хотите, использовать свой VCS в качестве вашей резервной системы.
Это абсолютно не связанные вещи. Подумайте об управлении версиями как о "машине времени", которую вы можете использовать, чтобы идти взад и вперед вовремя с вашим кодом.
На этом базовом уровне нет разницы между управлением версиями и резервными копиями. Система управления версиями - это инкрементное резервное копирование всех сделанных изменений. Базовый, не распределенный VCS, такой как CVS, используемый одним разработчиком, просто создаст резервную копию всех изменений, которые сделаны в текстовом файле.
Если управление версиями выходит за рамки базовых резервных копий, это дополнительные инструменты, которые предоставляются для сравнения версий, слияние изменений, сделанных несколькими разработчиками, версии тегов для выпуска или тестирования и проведение других операций, которые позволяют управлять этими отдельными версиями.