> I have an entire hierarchy of workspaces to convert to Mercurial. > Consider the following small subset of this hierarchy: > > onnv-gate > | > clearview-ot > | > seb_iptun > > This should become: > > onnv-gate-hg > | > clearview-ot-hg > | > seb_iptun-hg > > I did the following: > > 1. wx2hg clearview-ot > > This worked flawlessly. Our local onnv-gate has an hg_twin file and a > clearview-ot-hg workspace was created. clearview-ot and clearview-ot-hg > now contain identical sets of files, right? Hold that thought.
Mostly correct. The clearview-ot-hg working directory should have your changes, but unless you also did an "hg commit," then your hg metadata does not (yet) have those changes. So a subsequent "hg pull" from this repo won't see anything that isn't (yet) committed. Hold that thought. > 2. Create a clearview-ot/Codemgr_wsdata/hg_twin file which points at the > newly created clearview-ot-hg to facilitate the wx2hg of seb_iptun and > other children. > > 3. wx2hg seb_iptun > > This trudged along for a while, then failed with: > > <large spewage of diffs to stdout omitted> So does this large spewage happen to match the changes from seb_iptun to onnv-gate? > wx2hg: For file: > > usr/src/cmd/dladm/dladm.c > > the teamware parent: > > /export/ws/clearview/clearview-ot > > doesn't match its mercurial twin; specify the matching revision in mercurial > with -r hg_rev, or resynchronize them. > > Please run > hg --cwd /export/ws/seb/seb_iptun-hg update -C > > Huh? Since wx2hg succeeded on clearview-ot, I would have expected that > clearview-ot and its "twin" clearview-ot-hg would have identical sets of > files (that's the whole point, right?). A manual diff of that file in > clearview-ot and clearview-ot-hg shows that the file contents are in > fact identical. Can someone hit me with the clue-stick please? Again, that's to be expected (contents correct in working directory). The more interesting question isn't dladm.c in clearview-ot-hg; it's dladm.c in seb_iptun-hg. --Mark, hopefully not barking up the wrong tree