Fossil doesn't want to merge most recent changes between branches
(1) By Andy Bradford (andybradford) on 2021-02-04 14:47:18 [link] [source]
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
(2) By anonymous on 2021-02-05 01:01:12 in reply to 1 [link] [source]
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.
(3) By jamsek on 2021-02-05 02:53:41 in reply to 2 [link] [source]
I don't have any explanation for this problem, but have tested your
report and can confirm the same findings. It's certainly worrying,
though, so I hope it can be resolved. I am glad that you were able to
sort through the mess by hand easily enough.
(5) By anonymous on 2021-04-06 08:33:59 in reply to 2 [link] [source]
I finally cleaned up the apparently mess in the repository by hand.
Was there a 'mess'? Looked like a normal development history.
It is puzzling why merge would skip the files which diff does show as different. Especially when the two branches have a recent merge point ( http://tdom.org/index.html/info/57df626882287c7a ).
Clearly, the 'generic/schema.c' artifacts are differing between the merging revisions: http://tdom.org/index.html/fdiff?v1=aa6cde837afcd774&v2=2aa1c1e8ce09ee78.
Could this be due to the amend change ( http://tdom.org/index.html/info/746640dd2275dfb0 ) that intertwined after the 2aa1c1e8 artifact's commit?
(6) By anonymous on 2021-04-07 17:55:13 in reply to 5 [source]
Indeed, there's very odd Fossil merge behavior taking place in this repo. This calls for someone more familiar with the internal mechanics of the Fossil's merge to debug to the real cause. I agree, we've all accustomed to trusting Fossil operations to do what should be done, yet clearly in this case it fools us somehow.
I managed to track this down to a specific point at which the merge from trunk results in a common artifact (9a192e77c1f88) of 'generic/schema.c' in both trunk and toschema branches checkin:1be8c0f9cb49e3b3. Note, this merge did pick up the correct artifact from trunk to update the 'generic/schema.c'.
The 'generic/schema.c' is then changed on trunk to artifact 67dd664465. Yet the subsequent merge checkin:c3bbc18ae95c152c from trunk into toschema fails to pick up this updated artifact.
I see no valid reason why this artifact should not be picked up for merge. Yet this issue is still reproduceable from this repo,as shown below:
fossil info c3bbc18ae95c152c ## the "incomplete" merge
hash: c3bbc18ae95c152c99e8da5198a0519a7625418c 2020-11-13 00:27:02 UTC
parent: 1be8c0f9cb49e3b3618708b700778ae975d42cde 2020-09-24 16:42:23 UTC
merged-from: a8fac2ca99903be74f42f7c9c6ad10fbf4172564 2020-09-26 13:45:23 UTC
child: 8a31ad8fc5f5c39db2014c9a918c2b76fa005050 2020-11-13 01:05:56 UTC
tags: toschema
comment: Merged from trunk. (user: rolf)
fossil finfo generic/schema.c | grep "\[1be8c0f9cb\]"
2020-09-24 [1be8c0f9cb] Merged from trunk. (user: rolf, artifact: [9a192e77c1], branch: toschema)
fossil finfo generic/schema.c | grep "\[a8fac2ca99\]"
2020-09-26 [a8fac2ca99] Applied spell fixes provided by Gustaf Neumann (slightly modified and enhanced). (user: rolf, artifact: [67dd664465], branch: trunk)
fossil checkout 1be8c0f9cb
fossil merge a8fac2ca99 ## expected to update 'generic/schema.c' to the artifact: [67dd664465]
UPDATE extensions/tnc/tnc.c
UPDATE generic/dom.c
UPDATE generic/dom.h
UPDATE generic/domalloc.c
UPDATE generic/domalloc.h
UPDATE generic/domhtml.c
UPDATE generic/domhtml5.c
UPDATE generic/domxpath.c
UPDATE generic/domxslt.c
UPDATE generic/tcldom.c
UPDATE generic/tclexpat.c
UPDATE generic/tclexpat.h
UPDATE generic/tclpull.c
UPDATE generic/tdom.h
UPDATE generic/xmlsimple.c
Looks like a legit case of a failing/incomplete merge (the artifact 67dd664465 to update the 'generic/schema.c' is not picked up as it should).
(4) By anonymous on 2021-04-03 08:52:38 in reply to 1 [link] [source]
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?