Nathan Bush <nathan.bush at sun.com> writes: > Richard Lowe wrote: >> Mike Kupfer <mike.kupfer at sun.com> writes: >> >>>>>>>> "Nathan" == Nathan Bush <nathan.bush at sun.com> writes: >>> Nathan> webrev tries to execute "hg diff -g -r $HG_PARENT $CWS/$DIR/$F". >>> Nathan> In the case of this file, there is a strange discrepancy and the >>> Nathan> rename is getting lost. For example, if I try the same command >>> Nathan> manually, it is shown as a new file: >>> >> >> [much snipping] >> >>> I wish I understood the implications of this, especially for Cadmium. >> >> This problem, and similar, are why hg-active exists. The effort to >> make webrev do the right thing in the face of branches and merges >> using purely the CLI was too great to bear, so we didn't. If that's >> going to be the same in this case, I'd advocate the same solution, >> teach hg-active to spit out the info you need (which is trivially >> available there, as best as I can tell). > > I think there is already enough information available to webrev to > detect this situation, since hg-active provides both the old and new > filenames in case of a rename. I think webrev could be changed to > check that if the hg-active output reflects a rename, but the first > diff did not show it as one, try a second time with the other filename. > This would give one "deleted file" diff for the old filename, and one > "new file" diff for the new filename. It's enough to get the permissions > for both.
That's great too, I was just giving you a path that would make it trivial, if you needed/wanted one. >> >> I'm not sure what implications you're expecting for cdm? >> >> The behaviour described above is also not the same with 1.0, against >> 6349:0f466480ceaf it notices the rename. >> >> The fact the results differ between the two sides of a merge is, I >> think, correct. When you say "if you think of the repo as having two >> unnamed branches", this is literally the truth, and the behaviour we >> get now is what I'd expect from that. The diff is between the >> absolute revisions specified, not across a path in the history between >> the two. > > Does this mean we should use different terminology on the webrev > index page if the parent and child are on different branches? Such > as "compare to" instead of "rename", "no comparable file" instead > of "deleted", etc? In other words, the branches could be evolving > towards the same eventual merge but at different rates -- how do we > know, when comparing two revisions from arbitrary points on each > branch, if a particular file is deleted or just not yet created? I guess at this point we trust the file list to say sensible things, if passed by hand. The list you get from hg-active already makes sure the 'parent' comes logically prior to the child, my current thinking is that getting into the situation you describe would involve someone passing a file list that fairly explicitly asked for something non-sensical, again, I may be missing something though. -- Rich
