Fossil Forum

Fossil doesn't want to merge most recent changes between branches
Login

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?