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
