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
