Hello,

Apparently  Fossil doesn't  want to  merge some  of the  changes between
049f31fab5 and de524342e3 on http://tdom.org/index.html/timeline

When I run:

fossil update de524342e3
fossil merge  049f31fab5

it  does  not show  any  modifications  were made  to  generic/schema.c,
however, the manifest in 049f31fab5 shows an artifact hash for that file
as  aa6cde837afcd  and the  manifest  in  de524342e3 shows  a  different
artifact hash for the file  as being 2aa1c1e8ce09e. Post-merge what ends
up being committed is 2aa1c1e8ce09e as can be seen here:

http://tdom.org/index.html/info/b6edca9a2bdc13b9

If I look at a diff between the two nodes it shows:

http://tdom.org/index.html/vdiff?from=de524342e322ba38&to=049f31fab5a6ce18

So Fossil knows there are differences in generic/schema.c between those,
yet when I try to merge it doesn't?

I  did some  investigation and  found  that when  I run  the merge  with
--verbose, it shows this:

$ fossil merge --verbose 049f31fab5
merge-from: [049f31fab5] by rolf on 2021-02-03 22:53:46
            Added a way to express "at least n times and then unbound" in tdom
            schemas. (trunk)
baseline:   [2b327d36f3] by rolf on 2020-12-31 01:18:08
            Correct cleanup in case of failing conversion of a dom tree into an
            xslt command. (trunk)


And generic/schema.c is not one of the files that has an UPDATE.

If instead I override the baseline:

$ fossil merge --verbose --baseline 57df626882 049f31fab5
merge-from: [049f31fab5] by rolf on 2021-02-03 22:53:46
            Added a way to express "at least n times and then unbound" in tdom
            schemas. (trunk)
baseline:   [57df626882] by rolf on 2021-01-03 01:37:12
            Merged from trunk. (toschema)
...
UPDATE generic/schema.c


As can be seen, it does want to UPDATE generic/schema.c. I'm not sure if
my selection of baseline is appropriate, however, the merge does want to
change generic/schema.c and  the diff seems to show that  it is bringing
in the  correct code. Here's  a little more  info that seems  to confirm
Fossil's choice of baseline:

$ fossil test-ancestor-path de524342e3 049f31fab5
   1:  7722 049f31fab5a6 2021-02-03 22:53:46 VERSION2
   2:  7707 afd73d0e7f72 2021-02-01 23:58:28
   3:  7708 014e6256e705 2021-01-28 00:30:56
   4:  7696 7f9ca994ecd3 2021-01-22 17:31:08
   5:  7695 575f0e9e63c8 2021-01-22 01:07:31
   6:  7692 77f3b8498bc1 2021-01-22 01:05:32
   7:  7672 2b327d36f3d7 2020-12-31 01:18:08 PIVOT
   8:  7651 57df62688228 2021-01-03 01:37:12
   9:  7674 de524342e322 2021-01-29 20:12:01 VERSION1


Any  thoughts  as  to  why  Fossil   seems  to  prefer  the  version  of
generic/schema.c that  is in the toschema  branch instead of the  one on
trunk?

Thanks,

Andy

To move on, I finally cleaned up the apparently mess in the repository
by hand.

Picked, what's new in branches toschema and wip, closed both branches
and created a new branch toschema from trunk with my copies ("merged
by hand").

Which was all, what I wanted to do: to bring up my feature branch to
what happend on trunk in the meantime.

Almost all new code in the feature branch was in new files, so
hand-merging wasn't really hard. And the hindered code archaeology
is only a general consideration, not worth to call a problem in this
case.

The biggest thing is that I realize how much I bank on that fossil
just works. As I expect.

It always did. And in the rare cases not, my mistake quickly turned
out.

But this time ... I still would love to hear an explanation what
happens here.

To heal my basic sense of trust into fossil, a bit.

I think I just encountered the same problem. 
In my case, I have a develop branch and a deploy branch where all
the code, when it's considered stable, is merged to be deployed
elsewhere. When I try to merge from develop to deploy, not every
change is merged (some files are merged and some aren't). 
I had to cherrypick the checkins to bring
the changes to the deploy branch. Probably if I had overridden
the baseline, Fossil would have done the merge correctly, but I
just saw this thread.
Any thoughts?