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.

hg --close-branch updates tip :-(

Here's something joyful: when you close a branch in Mercurial, e.g. via

  hg update -C branch-to-be-closed
  hg commit --close-branch -m 'branch to be closed'

it becomes the "tip" - the most recent changest.

Many tools confuse "tip" with something like "the tip of the default branch".  And do stuff like checking out or diffstat'ing with tip.

Which probably is not what you want for a closed branch.

Merge node common to several branches

Noticing a pattern:

  hg branch b
  ... edit b ...
  ... test ...
  hg merge -r default
  ... test ...
  hg ci -m 'merged default into b'
  hg update -r default
  hg merge -r b
  ... diff -r default -r b
  ... test ...
  hg ci -m 'merged from branch b into default (after already merged default into branch b, i.e. identical node in both default and branch b'

This seems suboptimal.

It seems to me that instead of creating the same node, wrt content, on two branches, in this case default and b, we could create it once.  And link it in to both branches.

Key: must remember that the node is on both branches, so that afterwards can continue working separately.

I.e. could have updated to the merge node M but be on the default branch.  Or on the b branch.  (Or possibly both?)


It may be common to end a branch at such a merge node.  Perhaps commn enough to be the default.  But not univeral.  

Postfix if with else

Today I found myself writing

   do A if possible, else do B if possible, else error

English that is.

But it caused me to think about Perl's Postfix if

     statement if condition;
  versus
     if( condition ) {code} [[elsif(cond) {code}]* else {code}]
  i.e.

     if( condition ) {code}
     if( condition ) {code} else {code}
     if( condition ) {code} elsif(cond) {code} else {code}
   etc.

Strange to many programming languages, but sometimes makes conde more readable.

I wonder if the posifix if woth else, that I wrote in English, might be worth thinking about.

Syntactically  it is a ternary operator:
      operand1  IF operand2 ELSE operand3

I vaguely recall disjoint operator and function syntax - Algol 68? or was it Algol 60? - ...

Reading email in more than place

Andy Glew

1:55 PM  -  Public

I read email in more than one place, on more than one device, in more than one situation (phone (actually, PDA, but that's a story in itself), tablet, tablet PC by itself, tablet PC docked with 4 big monitors).

I need more dispositions than Archive or Delete.

I need "I can't read this now/here/on this device".

I suppose that it might be useful to be able to say where I could read it - e.g. "defer reading until I'm docked at my desk with 4 external monitors".

But "I can't read read it {in this situation}" is a simple button. It could probably fit on my phone's screen.  Whereas "Defer to another situation" is a multi-valued control, and harder to fit.

Note that "I can't read it in this situation" is NOT the same as "Later".  It may be a superset.  But being re-presented an email to read, later, on the same device that it was too painful to read on in the first place doesn't help.

--

Possibility of learning: record where deferred, and where finally read. Infer. Next time the user presses the "I can't read this {in this situation}" button, you might prompt "Read it at home?"

--

As usual, if already available, I'd like to hear about it.

Error Handling

I sometimes say "the most important part of programming is error handling".

This is not true. Shown by how many programs, how many library routines, how much code, does not handle errors at all.  Successful programs, libraries, code.

How about "one of the hardest parts of programming is error handling"?  That error handling is hard is one of reasons it is so often neglected.

And "one of the biggest barriers to reuse is error handling".

In at least two senses:

(1) You pick up a tool or library, try to use it on what you believe to be correct input - and it craps out with something like a Python stack dump.  Rather than debug, you try something else. Whereas, if an error message had explained what the problem was - if the code had checked format, rather than assuming - then you might have fixed the input.

(2) In a much narrower sense, the error handling conventions a code assumes may get in the way.  E.g. I assume that you throw an exception, you assume that it returns 0. Or -1.  If throwing an exception, what type of exception object do I throw?  (I have given up, and just throw strings.)


Can you tell I am debugging Python today?  I'm not 100% sure, but the Python code I have encountered has made more such assumptions...

The Joel Tests "best tools money can buy" and free software

I like the Joel Test:

http://www.joelonsoftware.com/articles/fog0000000043.html

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

But some of the questions have set me to musing.

E.g. 9 Do you use the best tools money can buy?

One might interpret this as saying that it is unreasonable to use free or Open Source tools, if there are tools that can be bought that are better.

But: better is arguable.  The fact that something is free, or, better, Open Source, greatly reduces many hassles. E.g. "We can't have your work on XYZZY because that would need a new license." 

(By the way: SW can be free but not Open Source, or vice versa.  Best if its free and Open Source.)

Joel's examples talk mainly about being wiling to spend money on fast computers for builds and tests, extra monitors, and disk space wars.  Mentioning a software tool, a bitmap editor, only as an aside.

But let's talk about SW tools, fre and Open Source.

I think here the proper way to consider this question is "Do you have the latest and greatest versions of the free and Open Source tools you are using installed?"

Or rather, since I am not an advocate of gratuitous feature creep: are you ever held back by lack of a feature in the version of free and Open Source tools you have installed --- that is fixed in more recent, stable, versions that will probably run on your machines?

One of the nice things about virtual machines is that more and more you can have N different distros running, so you can pick which tool versions you need.