"Mark J. Nelson" <Mark.J.Nelson at Sun.COM> writes: > So Dan threw us for a loop, which Rich eventually figured out. > > Summary of what Dan was seeing: > > 1. Dan changed usr/src/uts/intel/ip/ip.global-objs.debug64 to remove > udp_version. Same story for obj64. This was in a changeset along his > own development branch. > > 2. Dan then committed another changeset on his development branch to > restore those symbols. > > 3. Later, when Phil Kirk pushed the Clearview changes, he ALSO removed > those symbols. > > If you do an "hg log -r X" to show any of these three changesets, it > correctly identifies changes to the appropriate files. > > If you do "hg log filepath" to work backwards from the file to the > changeset, it does NOT identify change number 3. > > If you do "hg log -I filepath" to work backwards from the file to the > changeset, but use a Mercurial pattern instead of an explicit filepath > (even though you have given the same, explicit path) it DOES correctly > show all three changes.
Not backwards from file -> changeset, that's what 'hg log <file>' is doing, "the fast path", "the broken path". Using patterns forces the slow path, which goes forward from changeset -> file. > What's going on: the manifest for changeset 3, above, is actually > pointing to the filelog entry for changeset 1, above. Because the > versions of the file are exactly identical. So there is *no* entry in > the filelog for changeset 3. > > It is further likely that this is triggering Mercurial issue 1327, in > which merge is choosing the wrong ancestor for comparison during the merge. > > Which is seriously bad juju: in Dan's case, Mercurial chose an ancestor > changeset that was NOT IN THE LINEAR HERITAGE OF BOTH CHILD AND PARENT. > > The consequences of which may be left as an exercise for the interested > reader. Hint: it is impossible to merge correctly under these > circumstances. :( > > --Mark
