Could you review: 431 cdm should see merges as modification 432 cdm may lose files removed in confusing merges
Webrev: http://cr.opensolaris.org/~richlowe/scm_431 Bugs: http://bugs.grommit.com/show_bug.cgi?id=431 http://bugs.grommit.com/show_bug.cgi?id=432 There should be appropriate commentary in the bugs. I'd like to specifically call out the logic of #432, which is the removal of the lines at: http://src.opensolaris.org/source/xref/scm-migration/onnv-scm/usr/src/tools/onbld/Scm/WorkSpace.py?r=6243#194 This is not without risk, as this certainly used to be a problem. However, that logic is incorrect and the root cause of #432. I cannot reproduce the original problem (after much effort), and more strict checking there is unlikely to be completely correct without the ability to reproduce the original problem (which may now no longer occur). I'd prefer to remove this code, and, should the original problem still be present, use that to form a real fix that doesn't re-introduce #432. At present, the other options for fixes I can come up with are little better than bandaids that either risk being too broad (and dropping files) or too narrow (and showing phantom changes). The latter is clearly safer, and, given that, I think it better to remove the bandaid (which may show phantom changes in the AL, but will not lose files), than to possibly continue to lose an ever-shrinking subset. The downside is that recommit will try to commit to every file in the active list, such that these phantoms may gain an extra changeset in that case (or given the phantoms are removal, recommit may fail in the commit step) I would expect code reviewers, and anyone else to be playing close enough attention to their file list that this would be reflected in a bug being filed, rather than phantom changesets, but I'm not certain. (And, for the record, I don't particularly like the choices involved there either. Sorry, it's my fault) -- Rich
