Continuing a series showing a Subversion merge/cherry-pick bug that is not in Git, or Mercurial, or Perforce and now Fossil.

To recap, here is Subversion blowing up in a merge scenario after a series of cherry-picks, when it shouldn’t have done, from that previous blog entry:

Attempt redundant merge of branch two into branch one (individual commits are merged already, and files at HEAD revision are idential):
--- Merging r2 through r13 into 'one':
C    one/testfile.txt
--- Recording mergeinfo for merge of r2 through r13 into 'one':
 U   one
Summary of conflicts:
  Text conflicts: 1
Conflict discovered in file 'one/testfile.txt'.
Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
        (mc) my side of conflict, (tc) their side of conflict,
        (s) show all options:

So here are the same bash scripts, but issuing Fossil commands rather than subversion ones (link to Github repo/branch).

And the diff between the Git and Fossil versions of the same scripts. The fossil version is closest to the Git script, and it is what most people know.

The same two tests again…

Test one - merging one way - all good

./reset.sh
./test_of_out_order_merges_from_one_branch_to_another.sh

Merging changes out of order from branch ‘one’ to ‘two’ worked fine. Git Script:

test_of_out_order_merges_from_one_branch_to_another.sh

$ ./test_of_out_order_merges_from_one_branch_to_another.sh
project-id: c5ec2132c05de779eb990322669f5540cb639769
server-id:  457b6690ee7858ac6bca9c61e33ad0ce4cb4df90
admin-user: paul (initial password is "08aa01")
project-name: <unnamed>
repository:   /scm/oss/subversion_testing/data/.fossilDB
local-root:   /scm/oss/subversion_testing/data/
config-db:    /Users/paul/.fossil
project-code: c5ec2132c05de779eb990322669f5540cb639769
checkout:     8b92655c2fb1bb2ed98c7f9c0a6f698636b0c75e 2016-06-18 10:43:28 UTC
tags:         trunk
comment:      initial empty check-in (user: paul)
check-ins:    1
New branch: ddc2994440cb700ecadbee2c0b1dfeac2e797e41
ADDED  testfile.txt
New_Version: 66e1684f4628f2070d3f1bf0c359c96b6fa7e79d
New branch: 3290a3a6d6d6beb200217b485317f2bb37779d93
testfile.txt
New_Version: 29db75087afcb739275769b6fe0e26cd53fd5429
testfile.txt
New_Version: 3c6352f91f2e32e778e2d9964d94ccf987f3d6db
New_Version: 89e71b5b8c8729b5367e9c1c2f17dfc9ccc4f8ac
New_Version: 462ddb5136d67b892e99919fd8a6781df9613df9
New_Version: f62dfc7337fa96ec1d9e0d19ce2f4b14f8d57a33
New_Version: 0ab7a518e9fd805df9f2e65a3734fc0f0cd6a3d5
testfile.txt
UPDATE testfile.txt
 "fossil undo" is available to undo changes to the working checkout.
New_Version: 39a87cc936db06ee564ec71d8892ef3de5e93750
MERGE testfile.txt
 "fossil undo" is available to undo changes to the working checkout.
New_Version: 44feae754a8c05af48c5b857677a44056d68cd37
MERGE testfile.txt
 "fossil undo" is available to undo changes to the working checkout.
New_Version: a4a56c11df06c6f7b53612e160b80b7e01b098da
MERGE testfile.txt
 "fossil undo" is available to undo changes to the working checkout.
New_Version: b7040af1b12b0e2f7d4c1cd3d4649d7972bb87ca
MERGE testfile.txt
 "fossil undo" is available to undo changes to the working checkout.
New_Version: c45aa94943b37b2e7f06eb09bb394b97c98e274d
MERGE testfile.txt
 "fossil undo" is available to undo changes to the working checkout.
New_Version: d614b934dc12aeee1312416c4f8e17f73853d4d7

Like Subversion, Git and Mercurial, after a series of seemingly complete (if out of order) cherry-picks, Fossil wants to do one more ghost merge that doesn’t have any details in the fossil history.

Fossil’s built-in web server.

Launching it:

cd data
fossil serve .fossilDB

Pointing a browser at http://localhost:8080:

Clicking on the top commit takes you to a view, where you can show diffs, and there are none for the “leaf” commit. That commit is the ghost commit I referred to earlier.

Test two - merging back - all good too

./reset.sh
./test_of_out_order_merges_back_the_original_branch.sh

For subversion, this one had a bug in it - or rather it highlighted a bug in Subversion. Script:

test_of_out_order_merges_back_the_original_branch.sh

This was merging another series of changes, as cherry-picks, back to ‘one’ from branch ‘two’. It worked without barfing, unlike the Subversion one (see previous that entry). Fossil like Git and Mercurial will also do a ghost merge from ‘two’ to ‘one’ even if all of the cherry picks have been done already. Again with no diffs in the “fossil show” equivalent for the last commit. The result:

$ ./test_of_out_order_merges_back_the_original_branch.sh
New_Version: 69f441a0c7f5d810b15635e41f0dab7aaee57fa9
New_Version: b3872115684ca2c4b0d6333d24c1457b07bc90fb
New_Version: f0934d524a1070320163315193425118c56b10af
New_Version: 29a00dcf0d32e703250f3debb58dbcf9a91bcd03
New_Version: 40e27bc6a642de9c54e37cca36d53b9c32d47a49
testfile.txt
UPDATE testfile.txt
 "fossil undo" is available to undo changes to the working checkout.
New_Version: b864dd6d1d10339026e93421992b4306d31483f3
MERGE testfile.txt
 "fossil undo" is available to undo changes to the working checkout.
New_Version: 8a07cb48fcb0db8df7471af2194e5ed8c664ba85
MERGE testfile.txt
 "fossil undo" is available to undo changes to the working checkout.
New_Version: f1d033d6bff1ebd709c2277bea33b44265c5915b
MERGE testfile.txt
 "fossil undo" is available to undo changes to the working checkout.
New_Version: d8defbf11e59867430f876e55aca352e1898f04e
MERGE testfile.txt
 "fossil undo" is available to undo changes to the working checkout.
New_Version: 0524168f0fd1abc645e3f9ab8125ea9fe4561524
Contents of testfile.txt on branch 'one':
a !! aa

b !! bbb

c !! cccc

d !! ddddd

e !! eeeeee

testfile.txt
Contents of testfile.txt on branch 'two' (they are the same, as a result of merges):
a !! aa

b !! bbb

c !! cccc

d !! ddddd

e !! eeeeee

testfile.txt
Attempt redundant merge of branch two into branch one (individual commits are merged already, and files at HEAD revision are idential):
MERGE testfile.txt
 "fossil undo" is available to undo changes to the working checkout.
New_Version: ceefd8e948fff3188c8740f30acb1b1d05bbf87f

I’d like to know more about Fossil’s limits. For example, can it handle 100Gb of stored files and history or have permissions on branches or directories? I don’t think so - it won’t allow you to clone/pull-down a single branch.



Published

June 18th, 2016
Reads:

Categories