Differences between current version and previous revision of VersionControlSystem.
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 21 | Last edited on Wednesday, June 24, 2009 9:06:44 pm | by AristotlePagaltzis | |
| Older page: | version 20 | Last edited on Wednesday, June 24, 2009 8:54:13 pm | by AristotlePagaltzis | Revert |
@@ -24,9 +24,9 @@
# ! 1+n: One Repository, Many Working Copies
The next evolutionary step was to decouple the repository from the working copy, so that there may then be many working copies. The exemplar in this class of systems, known as centralised [VCS]s, is [CVS]. It lifts the obvious restrictions of earlier systems with a design in which the repository is mediated by a server. Multiple users can collaborate by each checking out a private working copy of the project.
- Note that in [CVS], “checking out” no longer implies locking. (In other centralised [VCS]s, such as VisualSourceSafe
, it may. In some, such as PerForce, it is optional.) Checking in changes is simply blocked if someone else has already checked in other changes in the meantime. Before the latecomer is allowed to check in their own changes, they have to update their working copy with the upstream changes, resolving any conflicts manually.
+ Note that in [CVS], “checking out” no longer implies locking. (In other centralised [VCS]s, it may; eg. VisualSourceSafe
. In some, such as PerForce, it is optional.) Checking in changes is simply blocked if someone else has already checked in other changes in the meantime. Before the latecomer is allowed to check in their own changes, they have to update their working copy with the upstream changes, resolving any conflicts manually.
This works reasonably well. [CVS] ended up as the de facto standard for a decade.
However, its single-repository nature, subsequently adopted by most following major systems, perpetuates problems harking back to the earlier model – and adds new ones:''''
