New Webrev (23.1) pushed

[Peter Jones]

On Thu, Nov 08, 2007 at 04:48:38PM +0100, Jean-Christophe Collet wrote:

>> If I understand the latest support for automatically generating the
>> file list from "hg outgoing", both the file list and the diffs (if
>> no "-r") are generated relative to the lowest-numbered revision in
>> the outgoing list.  That seems fine if no changesets have been
>> pulled since the first unpushed commit, but if changesets have been
>> pulled from the parent (and merged), those files/diffs get included
>> too, which I don't think would be the typical desire-- I'm hoping
>> for a file list like the familiar Teamware "putback -n" behavior,
>> which I think would involve comparing the status of the repository
>> relative to latest changeset shared with its parent (but with
>> comments listed from every changeset in the outgoing list that
>> affected a given file).  Does that sound reasonable/feasible?
> 
> Unfortunately mercurial works quite differently from teamware and
> "hg outgoing" doesn't provide quite the kind of information we
> need. So I have to cross-reference that with "hg status". Hence the
> complicated script.

Right-- my question above is more about which revision to compare
against when it chooses based on the output of "hg outgoing".  The
current choice (OUTREV in the script) seems to be:

(1) the lowest-numbered revision in the outgoing list minus one

But in order to generate desired diffs in the case that changesets
have been pulled/merged since some of the outgoing commits, I'm
thinking that something like this would be preferable:

(2) the highest-numbered revision not in the outgoing list

When no changesets have been pulled/merged since any outgoing commits
(perhaps the common case), then (2) should be the same as (1) anyway.

[By the way, I have seemed to find that "hg status --rev $rev -aC"
does not report moved (vs. added) files properly in a changeset that
contains a merge of $rev with the changeset that originally moved the
file, so must craft an explicit file list to get the desired output in
that case-- may be http://www.selenic.com/mercurial/bts/issue760 ?]

>> I was hoping that I could manually achieve this effect by
>> specifying the "latest changeset shared with the parent" using
>> "-r", but when "-r" is used with no file list, it seems that the
>> file list is still generated based on the "hg outgoing" (or if
>> empty, "hg status") algorithm, which was surprising to me-- I would
>> expect it to generate the file list based on the status of the
>> repository relative to the specified revision, in the "-r" case?
>>
>> I tried an explicit file list too, but when an explicit file list
>> is given, it doesn't make any attempt to accumulate multiple
>> changeset comments per file, rather just including the comments for
>> the latest changeset affecting each given file (I think).  I might
>> expect the comment accumulation behavior to be orthogonal to
>> whether an explicit file list is given (like, it would always
>> include comments from all changesets in the outgoing list affecting
>> a given file).
>>
>> More about changeset comments: in the case described above where I
>> have pulled changesets from the parent and merged with committed but
>> unpushed changesets, even though I want diffs against the latest
>> changeset shared with the parent, I still want comments from all of
>> the outgoing changesets (not just, say, the comments from later merge
>> changesets), so that seems to suggest a need to use "hg outgoing" even
>> when "-r" is used and the file list is based on the specified
>> revision-- (or else maybe a different revision could be specified for
>> the purposes of comment accumulation?).
> 
> Ah yes, I didn't deal cleanly with -r in that case. I think I've
> made the proper changes now, and it should provide the right
> comments now.  Incidently using -r kind of makes "hg outgoing"
> un-necessary, since we'll use "hg status --rev <rev>" to generate
> the list.

(As above, "hg outgoing" is still arguably desirable with "-r" for
determining which changesets' comments to accumulate.  In version
23.3, I see that you do still do "hg outgoing" when "-r" is given.)

> It will work with a provided file list as well now.

Looking at version 23.3, I'm not sure.  ALL_CREV & OUTREV are only set
if flist_from_mercurial is called.  ALL_CREV being set is required in
comments_from_mercurial to activate what looks like the behavior I was
interested in (only comments from changesets in the outgoing list that
affected a given file).  And if there's an explicit file list but "-r"
isn't given, then because neither PARENT_REV nor OUTREV will be set,
the diffs will only be against the tip.  Again, whether or not there
is an explicit file list seems orthogonal to which revision to compare
against, so if "-r" is not given, I would except the same
outgoing-based algorithm to apply (unless "-N" is given); that was the
motivation for moving the "hg outgoing" outside flist_from_mercurial.
Also, the current "hg outgoing" command doesn't use OUTPWS.

In comments_from_mercurial, I don't understand the "hg log --rev
$LOWER_CREV:$UPPER_CREV ..." done in the "-r" case-- that seems to
duplicate comments generated in the following for loop (in the
opposite order), as well as some extras?

> All that being said, I think I will have to write a "How to use
> webrev with mercurial" document because it's becoming a bit complex,
> in particular with the DOs and DONTs. For instance it's a good idea
> to wait until after the webrev is done before doing an hg pull if
> you've commited.

Perhaps some of the cases I'm expressing interest in here will be
unusual with OpenJDK engineering practices, that's not clear to me
yet.  Still, I assume that some merging of pulled changesets will be
inevitable, and there will be a desire to see webrev-style diffs of
changesets after merging.

Cheers,
-- Peter