Okay, the consensus seems to be to treat -r as diff does, and I've fixed my implementation up to do that.
As a bone to throw to the MQ folks, would it be too confusing to say that if the argument to -r was a tag for an MQ-managed changeset, that it show the diffs that changeset introduces? A range of MQ changesets could work one way or the other, depending probably on what johnlev would prefer. :) I've toyed a bit with pbranches, and have a tentative implementation of -b, which gives you the webrev of the changes introduced on a named branch. One question that's come up, though, is that because a named branch can be merged into the mainline and branch off again, what should the behavior be? Rich and I agree (I think) that the diffs should be based off the most recent branch point, since once you've merged with mainline, diffs from any previous branch point will include diffs introduced on mainline that your reviewers probably don't care about. However, Rich and I differ on the comments. He holds that the comments in the webrev should be all comments on the branch, while I suggested that perhaps only the comments since the most recent branch point should be available (and possibly drop that in favor of the pbranch comment, which is maintained separately, if it's available). My rationale is that the intermediate work that was done prior to the merge is not terribly relevant to people who haven't been reviewing the project on an ongoing basis, and those who have probably should be given a webrev that takes them to the merge point, a webrev of the merge (both possible with -r), and then a webrev of the bits afterwards. Any thoughts on either interface? I hope that'll take care of it, so I can actually get this wad out for review and put back soon. Thanks, Danek _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
