I updated Mercurial issue 1327 and filed Mercurial issue 1430 for these problems.
The question "what (if anything) do we do about this now?" is still open. We can't really work around the problem without actually solving it. We don't know when Matt will get the fix. I think that we need a heads up to our developers, but that will need to include a statement of the problem, and how to tell if you're affected, and what to do about it. And "how to tell" and "what to do" are not things that I can (yet) phrase succinctly. Any suggestions? --Mark Richard Lowe wrote: > "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
