Richard Lowe wrote: > Mike Kupfer <mike.kupfer at sun.com> writes: > >> I have a nightly cron job to generate the project webrev. This morning >> I noticed errors like >> >> ERROR: set mode of >> /net/athyra/export/kupfer/tonic/src/onnv-scm/webrev/raw_files/old/usr/src/pkgdefs/common_files/i.confupdate
[...] > > That's the error you'd get from #465, but in a different circumstance. > Perhaps #372 doesn't deal happily with removed files? It's the same fail-safe message, but not really the same root cause as #465. webrev tries to execute "hg diff -g -r $HG_PARENT $CWS/$DIR/$F". In the case of this file, there is a strange discrepancy and the rename is getting lost. For example, if I try the same command manually, it is shown as a new file: % hg diff -g -r eec05ec913e7 /export/home/nbush/hg/scm-migration/onnv-scm/deleted_files/usr/src/pkgdefs/common_files/i.confupdate diff --git a/deleted_files/usr/src/pkgdefs/common_files/i.confupdate b/deleted_files/usr/src/pkgdefs/common_files/i.confupdate new file mode 100644 --- /dev/null +++ b/deleted_files/usr/src/pkgdefs/common_files/i.confupdate @@ -0,0 +1,85 @@ ...etc... webrev can parse only the new permissions from this, but because both the old and new names are in the input flist it needs to build both old and new file versions in the raw_files directory, and the error message is triggered because there is no permission data for the old filename. If I explicitly use a second revision "-r tip" in the diff command, it works as I expected: % hg diff -g -r eec05ec913e7 -r tip /export/home/nbush/hg/scm-migration/onnv-scm/deleted_files/usr/src/pkgdefs/common_files/i.confupdate diff --git a/usr/src/pkgdefs/common_files/i.confupdate b/deleted_files/usr/src/pkgdefs/common_files/i.confupdate copy from usr/src/pkgdefs/common_files/i.confupdate copy to deleted_files/usr/src/pkgdefs/common_files/i.confupdate If this were the output in the real case, webrev would see that no permissions were present in the diff, and would try the second method to get them (searching the manifest). It would not be correct to use "-r tip" in a fix for this, since that would ignore working directory changes. --Nathan
