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
