tla star-merge in the 1.1 branch

tla-1.1 (just the development sources, not the latest release yet) now
has  star-merge.

I've noticed that people often under-use and don't quite get
star-merge.  And, of course, among people who do use it, there were
constant complaints about some uncovered edge cases in the larch
version.

So, the tla version has simpler semantics and covers the edge cases.
The weird things you could do with the larch version that you can't do
with the tla version, you can do by mixing `undo' and `redo' with
`star-merge'.    Meanwhile, the "first merge from a branch" edge-case
problem is gone.

Help message included.  It probably has dumb typos and, generally,
people trying out and reporting bugs against the new star-merge is
welcome.

I think the remaining priorities in merge commands are better help for
merging after cherry-picking, and an easy way to do (possibly
interactive) 3-way merging.    3-way merging largely falls out of the
work done on the new star-merge.   Merging-after-cherrypicking?  I
wanna think about that a little more.

Say, what are the tools people actually use for interactive 3-way
merging?  Is this _really_ a critical feature, or is that just a
rumour?

-t

--------------------------------
https://www.paypal.com/xclick/business=lord%40emf.net&item_name=support+for+arch+and+other+free+software+efforts+by+tom+lord&no_note=1&tax=0&currency_code=USD

and

lord@xxxxxxx for www.moneybookers.com payments.
--------------------------------

random funny non-sequitor:

In my country, as in many, there's a nightly news program.   In the
early evening, they show "teasers" -- little commercials about the top
stories of the day.   Sometimes they don't phrase these quite right,
as in this true example:

        A small plane falls out of the sky and crashes into an
        apartment building.   What went wrong?   Find out at 11.

I think it's pretty obvious what went wrong:  A small plan fell out of
the sky and crashed into an apartment building. 


--------------------------------



merge mutually merged branches
usage: tla star-merge [options] FROM TREE [VERSION]

  -h, --help     Display a help message and exit.
  -H             Display a verbose help message and exit.
  -V, --version  Display a release identifier string
                 and exit.
  -A, --archive  specify a default archive name

Merge changes from FROM into TREE, considering common ancestry
in VERSION (which defaults to the default tree version of TREE).

The purpose of this command is to merge changes between development
lines which may have merged in both directions.   It uses merge history
to attempt to minimize the spurious conflicts that can arise from `mutual
merging'.

FROM indicates a revision (it may be specified as a version name,
indicating the latest revision in that version).

TREE is the project tree into which the merge will occur.

Both TREE and VERSION must have a non-empty patch-log for VERSION (e.g.,
log-ls of TREE for that version must produce a list of patches).

Star-merge works by computing the most recent ANCESTOR revision of TREE and
FROM (with respect to VERSION) and then applying the changeset:

         delta (ANCESTOR, FROM)

to TREE.

The "most recent ancestor" is defined as follows:

MAYBE_ANCESTOR_1 is defined as the highest patch level in the version of FROM
for which both TREE and FROM have a patch log.   In other words, it is the
latest revision of FROM's version already merged into TREE.

MAYBE_ANCESTOR_2 is defined as the highest patch level in VERSION for which 
both FROM
and TREE have a patch log.   In other words, it is the latest revision of 
VERSION
already merged into FROM.

MAYBE_ANCESTOR_2, if it is not "nil", was merged into FROM at some revision
of FROM's version, which we can call LAST_MERGE_INTO_FROM.

If both MAYBE_ANCESTOR_1 or MAYBE_ANCESTOR_2 are nil, star-merge can do nothing.

If just one of MAYBE_ANCESTOR_1 is MAYBE_ANCESTOR_2 is not nil, then that
non-nil value is ANCESTOR.

If both MAYBE_ANCESTOR_1 and MAYBE_ANCESTOR_2 are not nil, then 
LAST_MERGE_INTO_FROM
and and MAYBE_ANCESTOR_1 are compared (both are revisions in FROM's version).  
If
MAYBE_ANCESTOR_1 is the later revision, then MAYBE_ANCESTOR_1 is ANCESTOR, 
otherwise,
MAYBE_ANCESTOR_2 is ANCESTOR.