On Sun, Dec 12, 2010 at 07:30:49PM -0500, Richard Hipp wrote: > On Sun, Dec 12, 2010 at 7:24 PM, Joerg Sonnenberger <[email protected] > > wrote: > > Consider it a merge conflict. > > > > You mean refuse to do the merge?
Yes, at least automatically. > Certainly a conflict warning will be issued, but it seems like a flat-out > refusal to do the merge is the wrong approach. In addition to the conflict > warning, Fossil needs to do something with the file. Just mark the whole file with the usual conflict markers or the initial / final segment if the changes allow that. E.g. consider the removed file empty. > As I ponder this question further, I'm leaning toward making a DELETE action > override any EDIT or RENAME action. So if a file has been deleted in the > local version, then a merge from a version where the file still exists keeps > the file deleted. And if a file still exists in the local version, then a > merge from a version where that file is deleted cause the file to become > deleted locally. Any objections to this approach? Removing local changes is the worst possible action. I have had the problem more than once that I had changes for one file in a working copy and the file got removed, because the logic was refactored and included elsewhere. If the DELETE would overwrite the EDIT, I would have lost my work without any indications that I have at it. RENAME without change being overwritten is also problematic. A rename tends to have follow up changes e.g. in Makefiles. Joerg _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
