Here’s a merge conflict I thought should have been resolved automatically:
I have the trunk version from where the symbol RF_OUT is renamed to SRF_OUT in
the branch version. It has never been renamed to SRF_OUT in the trunk version
(yet).
When trying to merge (--cherrypick, actually) from trunk the specific check-in
(either by giving the branch name or the actual check-in ID) from the
development branch that has the needed change, I got the following unexpected
merge conflict:
<<<<<<< BEGIN MERGE CONFLICT: local copy shown first <<<<<<<<<<<<<<<
@?status RF_OUT,#?MsgOn,#?MsgOff,fWriteZ
======= COMMON ANCESTOR content follows ============================
@?status SRF_OUT,#?MsgOn,#?MsgOff,fWriteZ
======= MERGED IN content follows ==================================
@?status SRF_OUT,#?MsgOn,#?MsgOff,puts
>>>>>>> END MERGE CONFLICT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
As you can see, the common ancestor content shows the SRF_OUT label when that
label was named so only in the (under development) branch version.
Additional info that may help determine what went wrong:
The SRF_OUT is renamed in the first node of the new branch several check-ins
before the cherry picked one.
There have been two merged from the trunk (after the rename) but are unrelated
to this change and there were never any merge conflicts.
I expected the merged-in content to have completely replaced the local version.
Is there something I’ve done wrong that got fossil confused, is this a bug, or
simply a case of merge algorithm imperfection? But, what confused it? It
seems like a very simple change.
Thanks._______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
