Differences between version 15 and previous revision of VersionControlSystem.
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 15 | Last edited on Saturday, June 20, 2009 6:19:39 am | by AristotlePagaltzis | Revert |
| Older page: | version 12 | Last edited on Saturday, June 20, 2009 6:13:09 am | by AristotlePagaltzis | Revert |
@@ -24,9 +24,9 @@
Note that “checking out” no longer implies locking. Checking in changes is simply blocked if someone else has already checked in other changes in the meantime. The latecomer simply has to update their working copy with the upstream changes, resolving any conflicts manually, before they are allowed to check in their own changes.
This works reasonably well, so [CVS] was 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.
- Firstly, checking in changes under such a system requires a network connection, as do most operations related to the project history. Besides the fact that this makes offline work nearly impossible, it also imposes a major performance penalty, since networked operations are inevitably
slow. Some systems, like SubVersion, try to selectively speed up some of these operations by keeping more data in the working copy, but the benefit of this is uneven across operations. Further, high traffic repositories may require rather beefy servers and connections to sustain.
+ Firstly, checking in changes under such a system requires a network connection, as do most operations related to the project history. Besides the fact that this makes offline work nearly impossible, it also imposes a major performance penalty, since networked operations are inescapably
slow. Some systems, like SubVersion, try to selectively speed up some of these operations by keeping more data in the working copy, but the benefit of this is uneven across operations. Further, high traffic repositories may require rather beefy servers and connections to sustain.
Anything checked in is always public; this means one has to be very careful about the state of commits. It also makes it impossible to touch up history (eg. to fix common mistakes like forgetting to include a new file in a commit). Branches become a big deal: all commits are publicly visible, no matter how experimental. Also, branch names are forced into a global namespace so a lot of thought has to be given to choosing them.
Branching is problematic for more reasons too. Most of these systems do not support branch merging very well: after you do it once, the changes from the merged-in branch are mixed in without any tracking, so if later attempts to merge the same branch will result in lots of artificial conflicts. This makes it very difficult to keep branches in synch. But the longer branches go without merging, the more effort it takes to merge them. All this adds up to a large barrier, psychological and otherwise, against branching.
