I rsynced your repository over to my system. I then cloned it up to the changeset before your apparently-problematic merge (8041, including by necessity 8033). In the new, cloned repo, I then pulled over your development branch, up to the changeset that was the other parent of 8042.
When I repeated the merge, udp_version was automatically preserved. (I actually set premerge=false, so I could have chosen the other version, but I wanted to verify the merge as it was happening.) I then pulled again, up to the changeset before your next merge, and repeated the subsequent merge. I was completely unsuccessful in duplicating the corruption that you're seeing. I understand that the right thing, in regards to udp_version, is to remove it from the ip global object lists. But that is NOT what was done in your workspace, probably as the result of an implicit merge. Presumably, you have not set premerge=false in the [merge] section of your .hgrc? Where to go from here: I would consider doing what I just did, to recreate your workspace sans corruption. It's a pain in the neck, but it should work. You'll need to export your cset 8172, and apply it to your new repo (and review the results carefully), but all of the rest you should be able to get by with a single merge once you have pulled to tip from the clone. I will save the corrupted repo, and poke around some, and/or see if I can correlate it to a known hg bug or file a new one. Please confirm: it looks as if you have NOT used cadmium to recommit this workspace, right? --Mark Dan Mick wrote: > The repo is at /net/angus.west.sun.com/local/ws/onnv-spelling. There's > a ZFS clone of it at local/ws/onnv-spelling-clone for destructive > experimentation. > > The problem appears to be that the per-file logs don't mention the last, > later cset that affected them. > > hg status, hg outgoing, hg verify are all silent. > > So, the files I've noticed are > > usr/src/uts/intel/ip/ip.global-objs.debug64 > usr/src/uts/intel/ip/ip.global-objs.obj64 > > In their logs (hg log <path)), I see csets (I'm using both cset numbers > to give some easier idea of sequence within this repo): > > 7898:89d3a91734bc from me on Oct 20 > 7775:b56f236530b5 from me on Oct 03 > 7749:e809938bf15f from Thejaswini on Sep 29 > > If I hg log -v and look for that pathname, I see this cset which claims > to have affected the files: > > > 8033:faf256d5c16c from Philip Kirk, Nov 06 (the Clearview putback) > > but that cset doesn't show in the file log. > > If I hg update tip, I apparently do not get the contents of that latest > cset; I apparently get the version from 89d3a91734bc, the latest shown > in the file log > (the contents are at least identical from the tip update). > > If I hg update -r faf256d5c16c, I get the apparently-correct versions of > the files. > > If I hg update -r (8042:)5db3956eb2e8, which is the merge cset closest > to the Clearview cset, the file contents are indeed wrong...but hg log > -p -r 5db3956eb2e8 doesn't show those files being touched. (?!???!) > > so it seems like something went wrong with 5db3956eb2e8, but I have no > idea what... > >
