Script for automated pull+merge

[Benjamin Pollack]

On Apr 9, 2010, at 4:58 PM, Greg Ward wrote:
> 
> Huh.  Did you use the algorithm I sketched or something different?

As near as I can tell, your initial algorithm was also our initial algorithm.

> After talking to a co-worker, I've tweaked the planned algorithm a
> bit:
> 
>  pull from R1 to R2
>  if any branches in R2 have multiple heads:
>      get a working copy of R2 (clone? share? not sure yet)
>      for each branch with multiple heads:
>          update to branch head with lower revnum
>          merge with internal:fail
>          if merge failed:
>              warn: file-level merges needed on $branch              #
> instead of aborting
>          else:
>              commit "merge R1 to R2"
>      push to the real R2 (assuming we cloned rather than shared)
>      email warnings to responsible address
> 
> In other words, we've already jumped from your initial implementation
> (abort on merge failure) to your second implementation (push multiple
> heads to R2 and leave it up to a human to merge).  And it sounds like
> your experience with version #2 was worse than version #1.   Hmmmmm.

That's correct.  Just to kind of flesh out my response a bit more: while we know, from this list and the IRC channel, that new users routinely get confused with force-pushing new heads and the like, this workflow confuses even veteran Mercurial users.  For example:

Let's say we have the tree A -> B -> C.  When B pulls A, it can't merge, so there are multiple heads.  But now, since there are multiple heads, when C pulls B, it also can't merge.  And the poor sap who pulls from C will probably now have four heads in his repo--and because they're all anonymous, since Mercurial lacks Git-style named heads, there is no sane way for him to figure out what on Earth he should be merging with.  In fact, his only recourse is going to be to hit up "hg web" or run a series of "hg in"/"hg out" requests to figure out which heads are in B that aren't in A, etc.  This is assuming that he even knows that C is autopulling from A and B; otherwise, he's really screwed.

The above isn't a random example, by the way.  It happened fairly often during Kiln's own development, when we had the repository hierarchy stable -> QA-devel -> devel -> [personal repositories].  Bug fixes going into stable didn't always merge cleanly with the up-and-coming version QA was working with, which would stop the bug fixes going into QA-devel from propagating backwards to devel, and finally a random intern would be faced with trying to merge a bunch of nitty-gritty Kiln crap that they have no knowledge about.

I really want this idea to work.  I really haven't figured out how to make that happen yet.

--Benjamin