Во время просмотра учебника на 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?
В CVCS изменения синхронизируются вокруг единого центрального репозитория. Итак, фиксируя изменение, пользователь создает одну версию в этом репозитории для других.
В то время как в DVCS каждый пользователь имеет свою собственную независимую копию репозитория, и все ревизии (или коммиты) изначально идут сюда. Существует отдельный процесс синхронизации изменений между другими пользовательскими репозиториями с помощью команд fetch / push.
Это руководство ужасно неверно:
Вот что я могу сказать о распределении и централизации в моей собственной книге:
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.