Disclaimer

The content of this blog is my personal opinion only. Although I am an employee - currently of Imagination Technologies's MIPS group, in the past of other companies such as Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Monday, July 09, 2012

Notifications when changeGROUPs are pushed

The Mercurial mailing list archived at http://mercurial.808500.n3.nabble.com/hgext-notify-as-a-changegroup-hook-generates-a-diff-between-wrong-versions-td3988885.html (and elsewhere, ncluding Google groups) has recently discussed what hgext.notify should provide.

I have been annoyed by this, because currently it diffs tip.  And hg tip may not be on the default branch.  So if I check in stuff on a branch, the next changegroup after me will see hgext.notify diff against my changes.

I'm not ready to jump into the Mercurial mailing list.  Not enough context.  But let's think about it:

A changegroup - a set of changes being pushed together - is not necessarily connected.  It is possible that, e.g. there may be some changes on the default branch (i.e. the trunk), and some on other branches.

e.g.


old             changegroup 1  changegroup 2
---1d---3d---   ----6d-------  ---8d---
    \
     2b--4b--   --5b-----7b--
Currently, I believe hgext.ntify diffs 8d against 7b. Whereas it probably "should" be diffed against 6d. Similarly, 6d should be diffed against 3d. Moreover, in changegroup 1 there are two diffs of interest: 5b agauinst 4b, and 6d against 3d. By the way, I think that we are soon going to see a semantic split: (a) changegroup, a set of related changes, bersus something like pushgroup, a set of changes pushed together. A pushgroup might contain multiple changegroups. But this doesn't matter too much... Even with this distinction, a changehgroup may have multiple ancestors. The graph between old stuff and a changehroup may have more than one arc across it. So, what should you do? Hypothesis: if handling not changegroups, put individual revisions, (1.1) the default diff should be against the parent on the same branch. Mercurial has anonymous branches, so there might be too parents on the same branch. Need then to figure out which is most useful. I would say (1.2) if there is only one parent on the same brach that is in the old set, prior to the changegroup, use that. (1.3) if there is more than one parent on the same brach that is in the old set, prior to the changegroup, use the most recent. Or possibly the one that has the most/fewest diffs. Note that I am prioritizing to the same branch. If a changeset has parents on other branches, don't diff against them - unless they are the only branches. (which can happen when a branch morphs - since Mercurial dos not allow branches to be renamed retroactively). So, what about changegroups? The changegroup may be multiheaded, or not. If the changegroup only has a single head, you probably want to diff against the rev on the same branch as the head, in the old set, prior to the changegroup. Using the same prioritizations as above. If the changegroup has multiple heads, (a) you may want to diff each, or (b) you may want to select a most interesting head. E.g. the most recent. Or the most recent on the trunk.

No comments: