I'm implementing a -r option to webrev, which, generally, takes a revision range and creates the webrev from that range, without going off to the parent to figure out what's changed. It would thus also allow you to get the webrev of an existing changeset which may or may not be common to both your workspace and its parent.
Anyway, after some discussion with a few folks, there's a bit of disagreement about exactly what the arguments to -r mean. As I currently have it implemented, -r r1 changes from p(r1) to r1 -r r1: changes from p(r1) to tip -r r1:r2 changes from p(r1) to r2 where p(r) means "first parent of r". This is analogous to how the -r option to "hg log" works. In particular, "-r r1" would give you the webrev of the changeset r1, which is a useful concept for folks using MQ (where changesets are named via tags), or if you want to create a webrev of a historical changeset. However, there's no way to get a webrev including any changes made to the working directory, only changes already committed to one or more consecutive changesets. However, some folks suggested that "hg diff" may be a better template: -r r1 changes from r1 to WD -r r1: changes from r1 to tip -r r1:r2 changes from r1 to r2 The disadvantage (as I see it) is that you'd have to figure out by hand what the parent of any given changeset is, if you want the short form for MQ or historical usage (though the parentrevspec extension is useful here -- "-r r1" in the first implementation could be written as "-r r1^:r1" in the second. A compromise could be something like this: -r r1 changes from p(r1) to r1 -r r1: changes from p(r1) to WD -r r1:r2 changes from p(r1) to r2 That is, like the current implementation, except that the unbounded range would include the changes to the working directory. You could limit it to tip by using "-r r1:tip", as the "tip" tag is always defined. The disadvantage is that nothing else in mercurial really acts like this, so it might confuse everyone. And none of these try to define "appropriate" behavior for branching repositories, like those under pbranch control (mostly because I don't have any experience with pbranch yet, and cadmium can't deal with branches at all, to my knowledge). My feeling after spending a few minutes with pbranch is that you can either use -r to specify the range of revisions of the branch (or some subset thereof), or I can add a -b option later on to simplify generating the webrev for the entirety of the branch. Does anyone have any feeling for this? I'm tempted to implement the third option, and if people can't seem to figure it out, change it to the second, "diff-style" option, and see if it's any better. And that's probably what I'll do if I don't get a whole lot of response, so if you care, please speak up. Thanks, Danek _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org