1.1 --- a/en/daily.tex	Wed Nov 15 15:59:41 2006 -0800
     1.2 +++ b/en/daily.tex	Wed Mar 28 23:01:57 2007 -0700
     1.3 @@ -303,11 +303,11 @@
     1.4  propagation of changes happens when you merge after a rename as after
     1.5  a copy.
     1.6  
     1.7 -If I modify a file, and you rename it to a new name, then we merge our
     1.8 -respective changes, my modifications to the file under its original
     1.9 -name will be propagated into the file under its new name.  (This is
    1.10 -something you might expect to ``simply work,'' but not all revision
    1.11 -control systems actually do this.)
    1.12 +If I modify a file, and you rename it to a new name, and then we merge
    1.13 +our respective changes, my modifications to the file under its
    1.14 +original name will be propagated into the file under its new name.
    1.15 +(This is something you might expect to ``simply work,'' but not all
    1.16 +revision control systems actually do this.)
    1.17  
    1.18  Whereas having changes follow a copy is a feature where you can
    1.19  perhaps nod and say ``yes, that might be useful,'' it should be clear
    1.20 @@ -315,6 +315,56 @@
    1.21  this facility, it would simply be too easy for changes to become
    1.22  orphaned when files are renamed.
    1.23  
    1.24 +\subsection{Divergent renames and merging}
    1.25 +
    1.26 +The case of diverging names occurs when two developers start with a
    1.27 +file---let's call it \filename{foo}---in their respective
    1.28 +repositories.
    1.29 +
    1.30 +\interaction{rename.divergent.clone}
    1.31 +Anne renames the file to \filename{bar}.
    1.32 +\interaction{rename.divergent.rename.anne}
    1.33 +Meanwhile, Bob renames it to \filename{quux}.
    1.34 +\interaction{rename.divergent.rename.bob}
    1.35 +
    1.36 +I like to think of this as a conflict because each developer has
    1.37 +expressed different intentions about what the file ought to be named.
    1.38 +
    1.39 +What do you think should happen when they merge their work?
    1.40 +Mercurial's actual behaviour is that it always preserves \emph{both}
    1.41 +names when it merges changesets that contain divergent renames.
    1.42 +\interaction{rename.divergent.merge}
    1.43 +
    1.44 +I personally find this behaviour quite surprising, which is why I
    1.45 +wanted to explicitly mention it here.  I would have expected Mercurial
    1.46 +to prompt me with a three-way choice instead: do I want to keep only
    1.47 +\filename{bar}, only \filename{quux}, or both?
    1.48 +
    1.49 +In practice, when you rename a source file, it is likely that you will
    1.50 +also modify another file (such as a makefile) that knows how to build
    1.51 +the source file.  So what will happen if Anne renames a file and edits
    1.52 +\filename{Makefile} to build it under its new name, while Bob does the
    1.53 +same, but chooses a different name for the file, is that after the
    1.54 +merge, there will be two copies of the source file in the working
    1.55 +directory under different names, \emph{and} a conflict in the section
    1.56 +of the \filename{Makefile} that both Bob and Anne edited.
    1.57 +
    1.58 +This behaviour is considered surprising by other people, too:
    1.59 +see~\bug{455} for details.
    1.60 +
    1.61 +\subsection{Convergent renames and merging}
    1.62 +
    1.63 +Another kind of rename conflict occurs when two people choose to
    1.64 +rename different \emph{source} files to the same \emph{destination}.
    1.65 +In this case, Mercurial runs its normal merge machinery, and lets you
    1.66 +guide it to a suitable resolution.
    1.67 +
    1.68 +\subsection{Other name-related corner cases}
    1.69 +
    1.70 +Mercurial has a longstanding bug in which it fails to handle a merge
    1.71 +where one side has a file with a given name, while another has a
    1.72 +directory with the same name.  This is documented as~\bug{29}.
    1.73 +\interaction{issue29.go}
    1.74  
    1.75  %%% Local Variables: 
    1.76  %%% mode: latex