On 8/5/2015 12:34 PM, Matt Welland wrote: > On Wed, Aug 5, 2015 at 8:01 AM, Andy Goth <andrew.m.g...@gmail.com > <mailto:andrew.m.g...@gmail.com>> wrote: >> http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg20758.html > > I have had people I support run into that several times. It would be > really excellent to be able to tell users that they can refactor the > organisation of a project using mv, rm etc. on a branch and then merge > it back in. Currently it can't be done so I advise people that they > should freeze development, do the refactor, then restart development.
Have you read my follow-up emails? This part especially: "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." The issue is indeed a consequence of the design of the merge algorithm. Fixing it is going to take some thought. You probably should not reply to this email since it's getting far off topic. If you can, please reply to the original thread. > Fixing this and making mv semantics identical to Unix would be a big > win for fossil in my opinion. Agree. Thankfully, mv is going in the right direction. -- 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
