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

Reply via email to