Отслеживание изменений SVN и Git
Во время просмотра учебника на Lynda.com, посвященного распределенным системам управления версиями и централизованным системам управления версиями, я наткнулся на текст, который смутил меня о том, что Git отслеживает иначе, чем централизованные системы управления версиями. Я всегда думал, что упомянутая VCS отслеживает изменения, и при фиксации вы сохраняете моментальный снимок этих изменений в репозиторий, который используется для перехода от версии к версии. Но почему-то в следующем тексте утверждается, что Git так не работает.
Может ли кто-нибудь попытаться объяснить и прояснить это для меня?
In Git the changes are stored as change sets or patches, and we're focused on tracking changes not the versions of the document. Now that's a subtle difference, you may think, well, CVS and SVN those track changes too, they don't. They track the changes that it takes to get from version-to-version of each of the different files or the different states of a directory. Git doesn't work that way, Git really focuses on these change sets in encapsulating a change set as a discrete unit and then those change sets can be exchanged between repositories. We're not trying to keep up-to-date with the latest version of something instead the question is, do we have a change set applied or not?
Я бы сказал, что большие различия - это централизованная и децентрализованная, линейная история и история графиков DAG, отслеживание на уровне файлов и отслеживание на уровне репо. Те, кто уделяет большое внимание «отслеживанию состояния репозитория» и «отслеживанию изменений» (например, различия между способами сохранения изменений / состояния в Mercurial и git), спорят о семантике и мелких деталях, о которых большинству людей даже не нужно думать о.
Ответы 2
В CVCS изменения синхронизируются вокруг единого центрального репозитория. Итак, фиксируя изменение, пользователь создает одну версию в этом репозитории для других.
В то время как в DVCS каждый пользователь имеет свою собственную независимую копию репозитория, и все ревизии (или коммиты) изначально идут сюда. Существует отдельный процесс синхронизации изменений между другими пользовательскими репозиториями с помощью команд fetch / push.
... и, в конце концов, вам все равно придется фиксировать / синхронизировать изменения в централизованном репозитории Git / DVCS в большинстве случаев.
@bahrep Как правило да, и вы не обязаны синхронизировать только место, когда вы хотите сохранить / поделиться своими изменениями.
Это руководство ужасно неверно:
- Git не сохраняет наборы изменений. Git вычисляет ревизии, динамически, по запросу. (Git действительно выполняет дельта-сжатие внутри файлов пакетов, но файлы пакетов довольно хорошо скрыты по сравнению с моделью хранилища объектов Git, которая намеренно раскрывается через хеш-идентификаторы.)
- Это бесполезное различие при обсуждении распределенного и централизованного. (См. Также Кан ответ.)
Вот что я могу сказать о распределении и централизации в моей собственной книге:
The key difference between these two kinds of systems is that a centralized VCS has a designated master repository. There may be multiple copies of the master, or even multiple masters with some kind of synchronization protocol (e.g., ClearCase MultiSite), but there is only one master. Their design assumes this single-master-ship and thus is allowed to depend on it.
With a distributed VCS, there is no designated master repository. Users generally have a complete, private copy of each repository. Communications between these private copies are, at least in principle, peer-to-peer operations: neither repository is any more masterful, and conflicts—situations where both Alice and Bob have made changes to the same regions of the same files—can and do occur and require some kind of resolution.
It’s always possible to use a distributed VCS in a centralized manner: you simply designate one particular repository as the master version, and coordinate updates to it. However, centralized systems often provide features like locking source files or directories, restricting access (for read and/or write, to particular files, directories, and/or branches), and so on. With a typical DVCS it’s more difficult (though not technically impossible) to provide these, and Git and Mercurial simply don’t, at least not without add-ons. With CVCSes that provide locking, users may lock files (typically just one specific version ID) to prevent other users from making conflicting changes. This is conceptually easier, but of course it can prohibit parallel work.
Вы можете прочитать Глава 10 из Pro Git, в котором объясняется, как Git на самом деле хранит файлы. Короче говоря, каждая версия файла целиком хранится как «большой двоичный объект», а фиксация - это просто набор указателей на большие двоичные объекты, представляющие файлы в определенный момент времени. Две фиксации могут ссылаться на один и тот же большой двоичный объект, если файл не изменяется между фиксациями. Иногда для экономии места старые коммиты «упаковываются», и тогда коммит действительно представляет собой просто набор различий между файлами.