On 1/14/2016 3:51 PM, Steve Stefanovich wrote:
Re the failing merge tests you discuss:
> * merge_multi-4 > * merge_renames-5
... do you know if they are in any way related to previosly reported rename bugs below? Second one, in particular, makes code reorganisation painful. Cheers, Steve 1. (In May 2015) Anofos reported that renaming a file on the branch and adding it back later results in lost file when merged back to trunk. Git does the right thing. http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg20417.html
At quick skim, this looks like the issue that merge_renames-5 is testing, where in the email the renamed and freshly added file is named 'b' and in the test case named 'f1'.
That test case was introduced at checkin [25fe7658], and I'm not sure it has ever passed. At least, on my Windows box I've spot checked a handful of releases starting with that checkin, and have not found a working one. Specifically I checked [25fe7658], version-1.30, version-1.33, and [acbee54e8b]. All fail on merge_renames-5.
I'm wondering if the test case was written in hopes of fixing it, without anyone actually doing that.
(Aside: Should there be a third class of result for tests that we hope will someday pass but which document a known issue that is accepted as is? This case could be the poster child for that class.)
2. (In June) Andy G reported after renaming file in a branch, merging trunk changes to it works only once, and subsequent merges do nothing: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg20758.html
At a quick glance, this looks different that merge_multi-4. But I haven't looked deeply at that one yet.
-- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 _______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
