Behind the scenes

# HG changeset patch # User Bryan O'Sullivan # Date 1239084833 25200 # Node ID 2ff0a43f11521205acfa8da264d0e64bebb15637 # Parent 4e23c220d1b0dea899dae81e84398c23a9f2d302 Update ch03 diff -r 4e23c220d1b0 -r 2ff0a43f1152 en/ch03-concepts.xml --- a/en/ch03-concepts.xml Mon Apr 06 22:05:44 2009 -0700 +++ b/en/ch03-concepts.xml Mon Apr 06 23:13:53 2009 -0700 @@ -4,14 +4,16 @@ Behind the scenes - Unlike many revision control systems, the concepts upon which - Mercurial is built are simple enough that it's easy to understand - how the software really works. Knowing this certainly isn't - necessary, but I find it useful to have a mental - model of what's going on. + Unlike many revision control systems, the concepts + upon which Mercurial is built are simple enough that it's easy to + understand how the software really works. Knowing these details + certainly isn't necessary, so it is certainly safe to skip this + chapter. However, I think you will get more out of the software + with a mental model of what's going on. - This understanding gives me confidence that Mercurial has been - carefully designed to be both safe and + Being able to understand what's going on behind the + scenes gives me confidence that Mercurial has been carefully + designed to be both safe and efficient. And just as importantly, if it's easy for me to retain a good idea of what the software is doing when I perform a revision control task, I'm less likely to be @@ -436,19 +438,19 @@ a new head, because your working directory isn't synced to whatever the current tip is. - I put the word error in quotes because - all that you need to do to rectify this situation is - hg merge, then hg commit. In other words, this - almost never has negative consequences; it just surprises - people. I'll discuss other ways to avoid this behaviour, - and why Mercurial behaves in this initially surprising way, - later on. + I put the word error in + quotes because all that you need to do to rectify this + situation is hg merge, then + hg commit. In other words, + this almost never has negative consequences; it's just + something of a surprise for newcomers. I'll discuss other + ways to avoid this behaviour, and why Mercurial behaves in + this initially surprising way, later on. - Merging heads + Merging changes When you run the hg merge command, Mercurial leaves the first parent @@ -518,7 +520,25 @@ merge immediately becomes overwhelming. + + + Merging and renames + + A surprising number of revision control systems pay little + or no attention to a file's name over + time. For instance, it used to be common that if a file got + renamed on one side of a merge, the changes from the other + side would be silently dropped. + + Mercurial records metadata when you tell it to perform a + rename or copy. It uses this metadata during a merge to do the + right thing in the case of a merge. For instance, if I rename + a file, and you edit it without renaming it, when we merge our + work the file will be renamed and have your edits + applied. + + Other interesting design features @@ -575,8 +595,8 @@ compression package). This combination of algorithm and compression of the entire stream (instead of a revision at a time) substantially reduces the number of bytes to be - transferred, yielding better network performance over almost - all kinds of network. + transferred, yielding better network performance over most + kinds of network. (If the connection is over ssh, Mercurial doesn't recompress the diff -r 4e23c220d1b0 -r 2ff0a43f1152 en/figs/filelog.svg --- a/en/figs/filelog.svg Mon Apr 06 22:05:44 2009 -0700 +++ b/en/figs/filelog.svg Mon Apr 06 23:13:53 2009 -0700 @@ -2,7 +2,7 @@