Differences between version 16 and previous revision of VersionControlSystem.
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 16 | Last edited on Saturday, June 20, 2009 6:22:55 am | by AristotlePagaltzis | Revert |
| Older page: | version 15 | Last edited on Saturday, June 20, 2009 6:19:39 am | by AristotlePagaltzis | Revert |
@@ -34,9 +34,9 @@
Finally, the single-repository nature means that anyone who wants the safety of revision control needs to have write access to the same repository. And since branching is badly supported, everyone with access to the repository is generally going to be working on the same trunk. This means write access has to be given out selectively, to competent people only, resulting in political headaches within projects, while outsiders are forced to create their patches in an unversioned ghetto.
# The solution to all this was to not only give each collaborator a separate working copy, but a separate repository also. This class of system is known as DistributedVersionControlSystem~s. The technical basis that allows this is algorithmic merging: 3-way merging allows combining non-overlapping changes automatically, and merge point tracking allows repeatedly merging branches without unnecessary conflicts.
- Since each collaborator has their own repository and can make commits, the effect is that everyone has their own private branch, with full versioning for local changes, and these branches can easily
published and merged. Actually, each collaborator often has several local branches – since merging is easy and branches never ''need'' be published, it is painless to create short-lived branches for experiments or tests, to use them as a general workflow aspect (eg. start a new branch for every separate bug fix), or for any other purpose, whether intended for public consumption or not.
+ Since each collaborator has their own repository and can make commits, the effect is that everyone has their own private branch, with full versioning for local changes, and these branches can be
published at the discretion of their author
and can be
merged by others easily
. Actually, each collaborator often has several local branches – since merging is easy and branches never ''need'' be published, it is painless to create short-lived branches for experiments or tests, to use them as a general workflow aspect (eg. start a new branch for every separate bug fix), or for any other purpose, whether intended for public consumption or not.
Everyone has full offline access to the project history, and all repository operations (except pushing or pulling changes, obviously) take place at full local disk speed.
All this immensely accelerates collaborative development and removes the political headaches surrounding commit access.
