hgbook
changeset 256:649a93bb45ae
Fiddle with the sections on SVN and CVS.
author | Bryan O'Sullivan <bos@serpentine.com> |
---|---|
date | Sun Jun 03 09:49:14 2007 -0700 (2007-06-03) |
parents | 9c49615e8dcb |
children | d9d29e7cf5bd |
files | en/intro.tex |
line diff
1.1 --- a/en/intro.tex Wed May 30 22:19:56 2007 -0700 1.2 +++ b/en/intro.tex Sun Jun 03 09:49:14 2007 -0700 1.3 @@ -372,13 +372,20 @@ 1.4 one to learn to use the other. Both tools are portable to all popular 1.5 operating systems. 1.6 1.7 +Subversion lacks a history-aware merge capability, forcing its users 1.8 +to manually track exactly which revisions have been merged between 1.9 +branches. If users fail to do this, or make mistakes, they face the 1.10 +prospect of manually resolving merges with unnecessary conflicts. 1.11 + 1.12 Mercurial has a substantial performance advantage over Subversion on 1.13 every revision control operation I have benchmarked. I have measured 1.14 its advantage as ranging from a factor of two to a factor of six when 1.15 compared with Subversion~1.4.3's \emph{ra\_local} file store, which is 1.16 the fastest access method available). In more realistic deployments 1.17 involving a network-based store, Subversion will be at a substantially 1.18 -larger disadvantage. 1.19 +larger disadvantage. Because many Subversion commands must talk to 1.20 +the server and Subversion does not have useful replication facilities, 1.21 +server capacity becomes a bottleneck for modestly large projects. 1.22 1.23 Additionally, Subversion incurs a substantial storage overhead to 1.24 avoid network transactions for a few common operations, such as 1.25 @@ -388,10 +395,6 @@ 1.26 than, a Mercurial repository and working directory, even though the 1.27 Mercurial repository contains a complete history of the project. 1.28 1.29 -Subversion does not have a history-aware merge capability, forcing its 1.30 -users to know exactly which revisions to merge between branches. This 1.31 -shortcoming is scheduled to be addressed in version 1.5. 1.32 - 1.33 Subversion is currently more widely supported by 1.34 revision-control-aware third party tools than is Mercurial, although 1.35 this gap is closing. Like Mercurial, Subversion has an excellent user 1.36 @@ -440,13 +443,20 @@ 1.37 1.38 It has a centralised client/server architecture. It does not group 1.39 related file changes into atomic commits, making it easy for people to 1.40 -``break the build''. It has a muddled and incoherent notion of tags 1.41 -and branches that I will not attempt to even describe. It does not 1.42 -support renaming of files or directories well, making it easy to 1.43 -corrupt a repository. It has almost no internal consistency checking 1.44 -capabilities, so it is usually not even possible to tell whether or 1.45 -how a repository is corrupt. I would not recommend CVS for any 1.46 -project, existing or new. 1.47 +``break the build'': one person can successfully commit part of a 1.48 +change and then be blocked by the need for a merge, causing other 1.49 +people to see only a portion of the work they intended to do. This 1.50 +also affects how you work with project history. If you want to see 1.51 +all of the modifications someone made as part of a task, you will need 1.52 +to manually inspect the descriptions and timestamps of the changes 1.53 +made to each file involved (if you even know what those files were). 1.54 + 1.55 +CVS has a muddled notion of tags and branches that I will not attempt 1.56 +to even describe. It does not support renaming of files or 1.57 +directories well, making it easy to corrupt a repository. It has 1.58 +almost no internal consistency checking capabilities, so it is usually 1.59 +not even possible to tell whether or how a repository is corrupt. I 1.60 +would not recommend CVS for any project, existing or new. 1.61 1.62 Mercurial can import CVS revision history. However, there are a few 1.63 caveats that apply; these are true of every other revision control