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. > > 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? --Nathan > > Perhaps I'm not understanding though? > > -- Rich
