# HG changeset patch # User Jim Hague # Date 1238497751 -3600 # Node ID 8660df02d8a9cd8313b85419a88c0fc17ad5dc53 # Parent a942bf7bc2ab6369313afa665bf16e0f32cd7f9e More subediting. diff -r a942bf7bc2ab -r 8660df02d8a9 Hg.txt --- a/Hg.txt Fri Mar 06 21:17:07 2009 +0000 +++ b/Hg.txt Tue Mar 31 12:09:11 2009 +0100 @@ -75,8 +75,8 @@ o Speed. Mercurial is fast. In the same ballpark as Git. Bazaar wasn't, and although it has improved significantly, has, in my -estimation, added user complexity in the process, and is still off the -pace for some operations. +estimation, added user complexity in the process, and at the time +of writing is still off the pace for some operations. o Documentation. At the time, Bryan O'Sullivan's excellent Mercurial book (http://hgbook.red-bean.com) was a clear winner for best @@ -198,7 +198,7 @@ that you can't record an empty directory in your repository. (Footnote: I tripped over this converting a work Subversion -repository. One possibility is to create a placemaker file in the +repository. One possibility is to create a placeholder file in the directory. In the event I created the directory (which receives build products) as part of the build instead.) @@ -305,7 +305,7 @@ revision plus your change. Perhaps that's what Mercurial did? No. What Mercurial did is central to Mercurial's view of the -world. You took your working copy back to an old changeset, and the +world. You took your working copy back to an old changeset, and then committed a fresh change based at that changeset. Mercurial actually did just what you asked it to do, no more and no less. Let's see the initial evidence. @@ -486,9 +486,9 @@ answer'. I found the explanation helpful, so this section attempts the 10,000ft (FL100 if you prefer) view of Mercurial. -(Foornote: Bryan O'Sullivan's excellent Mercurial book has a chapter -on the subject, and the Mercurial website has a fair amount of detail -too. This is 'research', OK?) +(Foornote: For the curious, Bryan O'Sullivan's excellent Mercurial book +has a chapter on the subject, and the Mercurial website has a fair amount +of detail too.) First remember that any file or component can only have one or two parents. You can't merge more than one other branch at once. @@ -634,15 +634,16 @@ distributed manner, with full history and the ability to commit being available locally. -I want now to reflect on the consequences all this has for that -all-important question of whether a DVCS is a suitable vehicle for -your data. +So instead of chatter on about workflows, I want instead to reflect on +the consequences all this has for that all-important question of +whether a DVCS is a suitable vehicle for your data. The first is a minor and rather obvious point. If you want to store -files that are both very large and which change often in your DVCS, -then all the compression in the world is unlikely to stop the storage -requirements for the full project history from becoming -uncomfortably large. +files that are very large and which change often in your DVCS, then +all the compression in the world is unlikely to stop the storage +requirements for the full project history from becoming uncomfortably +large, particularly if the files are not very compressible to start +with. The second, and main, point is that there is an important question you need to ask about your data. We've seen that a DVCS relies on