New Webrev (23.1) pushed

[Jean-Christophe Collet]

Peter Jones wrote:
> Many thanks for your efforts with webrev for Mercurial.  A few
> comments/questions about the latest version (some or all of which may
> well be misunderstandings on my part-- and I'm not familiar with
> forests yet to understand how they might apply to them either):
>
> It now uses "sort -g", but /usr/bin/sort on my Solaris 10 box doesn't
> support "-g", wouldn't "-n" be good enough here?
>
>   

Ah yes, -g is not portable. I'll use -n instead. Thanks.

> 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.

> 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.

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

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.

In any case, version 22.3 is available.

> FWIW (not much I expect), below are diffs vs. version 23.2 for crude
> hacking I did to serve an immediate (non-JDK) need: file list is
> generated relative to specified revision when "-r" is used, and "hg
> outgoing" is executed even when an explicit file list is provided (in
> order to get comment accumulation)-- and there is another kludge to
> only include comments from the outgoing changesets, not changesets
> pulled from the parent (I thought that "hg log --follow-first" might
> help with that, but it didn't seem to).  And no consideration for
> forests...
>
> Cheers,
> -- Peter
>
>
>