|
Size: 201
Comment:
|
Size: 782
Comment: +cat
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| A centralised ["SCM"] stores all of its metadata in a single authoritative (or "master") database that is not replicated. ["CVS"] follows this model, as does ["Subversion"]. | A centralised ["SCM"] stores all of its metadata in a single authoritative (or "master") database that is not replicated (except possibly for backup purposes). ["CVS"] (and ["RCS"] and ["SCCS"]) follows this model, as does ["Subversion"]. ["Mercurial"] is a ["DistributedSCM"], which is a more general model that's a proper superset of the centralised SCM model. If you want to change your development pattern as little as possible and switch from ["CVS"] or ["Subversion"] for reasons of non-brokenness (["CVS"] does not have atomic commits), speed, or future flexibility, ["Mercurial"] can be used in a way that's very similar to most centralised SCM systems. Instructions on how to do this can be found at CvsLikePractice. ---- CategoryGlossary |
Centralised SCM
A centralised ["SCM"] stores all of its metadata in a single authoritative (or "master") database that is not replicated (except possibly for backup purposes). ["CVS"] (and ["RCS"] and ["SCCS"]) follows this model, as does ["Subversion"].
["Mercurial"] is a ["DistributedSCM"], which is a more general model that's a proper superset of the centralised SCM model. If you want to change your development pattern as little as possible and switch from ["CVS"] or ["Subversion"] for reasons of non-brokenness (["CVS"] does not have atomic commits), speed, or future flexibility, ["Mercurial"] can be used in a way that's very similar to most centralised SCM systems. Instructions on how to do this can be found at CvsLikePractice.