Re: [fossil-users] Renames and multiple merges
On 6/4/2015 7:33 PM, Andy Goth wrote: On 6/4/2015 12:44 PM, Andy Goth wrote: On 6/3/2015 8:27 PM, Andy Goth wrote: After renaming files on a branch, Fossil will allow you only one successful merge until it loses track of which files are which. Here's a sequence showing the problem (version 3ffb6a3e62): http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg20758.html My theory is that Fossil doesn't know about the renames if they happened before the nearest common ancestor. ** Rename files that have taken a rename on P-M but which keep the same ** name on P-V. If a file is renamed on P-V only or on both P-V and ** P-M then we retain the V name of the file. The merge algorithm of working from the nearest common ancestor is built on the assumption that everything before then has already been merged. That assumption does not hold in the situation given by the second sentence of the comment quoted above. Does anyone have any thoughts on this? This is still a major problem for me. Merging of renamed files does not work at all when the renames happened on the merged-into branch but before the most recent merge. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Renames and multiple merges
On 6/4/2015 12:44 PM, Andy Goth wrote: On 6/3/2015 8:27 PM, Andy Goth wrote: After renaming files on a branch, it seems Fossil will allow you only one successful merge until it loses track of which files are which. Here's a sequence showing the problem (version 3ffb6a3e62): [see http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg20758.html] My theory is that Fossil doesn't know about the renames if they happened before the nearest common ancestor. Looking at the merge code, I see this comment: ** Rename files that have taken a rename on P-M but which keep the same ** name on P-V. If a file is renamed on P-V only or on both P-V and ** P-M then we retain the V name of the file. Thinking about this further, it's making more and more sense. The merge algorithm of working from the nearest common ancestor is built on the assumption that everything before then has already been merged. That assumption does not hold in the situation given by the second sentence of the comment quoted above. I imagine the solution is to have separate common ancestors for file data and file names. For file data, the current algorithm is good: use the nearest common ancestor. But for file names, since name changes aren't always incorporated into the merge, pick the common ancestor only by looking at predecessors, without regard to merge cards. I'm not sure how to adapt this to the existing code. More thought is needed. Maybe it's as simple as passing a different pid value to find_filename_changes() in merge_cmd(), but I have a hard time believing this won't choke on more complex cases. Also pivot_find() would need to be changed to take an argument instructing it to honor or ignore past merges, and I don't feel I understand the database well enough to do that. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Renames and multiple merges
On 6/3/2015 8:27 PM, Andy Goth wrote: After renaming files on a branch, it seems Fossil will allow you only one successful merge until it loses track of which files are which. Here's a sequence showing the problem (version 3ffb6a3e62): [see http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg20758.html] My theory is that Fossil doesn't know about the renames if they happened before the nearest common ancestor. Looking at the merge code, I see this comment: ** Rename files that have taken a rename on P-M but which keep the same ** name on P-V. If a file is renamed on P-V only or on both P-V and ** P-M then we retain the V name of the file. In the first case (the successful merge), the rename is on P-V only. The file is named a in both P and M but renamed b in V. In the second case (the failed merge), there are no renames. P and M have a file named a, and V has an apparently unrelated file named b. Here's the output of the first merge, rerun with -v and -debug: merge-from: [9af3457a2e] by andy on 2015-06-04 17:37:36 2 (trunk) baseline: [16309abd54] by andy on 2015-06-04 17:37:36 1 (trunk) P=3 16309abd543dd0e8e4315a357e3ec0eea4bb7986 M=6 9af3457a2e67f1128c1c72afbe78221fc0915e8d V=4 86e3dedd7a825e861797522a61009ee45a014e10 P-V at 4 86e3dedd7a: 1[a] - 0[] P-V at 4 86e3dedd7a: 1[a] - 2[b] P-V summary 1[a] - 2[b] 1: ridv=2ridp=2ridm=5chnged=0 isexe=0 islinkv=0 islinkm=0 fn = [b] fnp = [a] fnm = [a] UPDATE b And the second merge, which fails to update b: merge-from: [35b5f2f6ed] by andy on 2015-06-04 17:40:08 3 (trunk) baseline: [5d7b980414] by andy on 2015-06-04 17:40:08 2 (trunk) P=6 5d7b980414c124cea1ac5d196528dd0be6a64610 M=9 35b5f2f6ed36d6819e6f545999b0ffb989afc937 V=7 1934161b59531bd188a9ad34201f01328859e800 1: ridv=5ridp=0ridm=0chnged=0 isexe=0 islinkv=0 islinkm=0 fn = [b] fnp = [b] fnm = [b] 2: ridv=0ridp=5ridm=8chnged=0 isexe=0 islinkv=0 islinkm=0 fn = [a] fnp = [a] fnm = [a] -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Renames and multiple merges
After renaming files on a branch, it seems Fossil will allow you only one successful merge until it loses track of which files are which. Here's a sequence showing the problem (version 3ffb6a3e62): f new merge-rename.fossil mkdir merge-rename cd merge-rename f open ../merge-rename.fossil echo hello a f add a f commit -m 1 f mv -hard a b f commit -branch branch -m 1.1.1 f up trunk echo goodbye a f commit -m 2 f up branch f merge trunk f commit -m 1.1.2 f up trunk echo broken a f commit -m 3 f up branch f merge trunk Everything is good until the final command, which only adds a MERGED_WITH record to the checkout but does not actually change any files. My theory is that Fossil doesn't know about the renames if they happened before the nearest common ancestor. This is causing major trouble for me since I have a branch in which everything was renamed to support a reorganization effort, yet I need to continue merging stuff from trunk which doesn't have the renames. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
