On Sat, Oct 15, 2011 at 06:32:53AM -0400, Richard Hipp wrote: > I will entertain arguments to move the merge-conflict reporting changes back > into trunk. But I need to hear some arguments in favor of that change > before moving forward with it.
In my last reply, I did not mention arguments; I was a bit in a hurry. Here I go explaining a bit the changes. I find it dangerous, if fossil overwrites a file I had in my filesystem, and it does not tell me specially about the overwrite. I know you understand the situation, but maybe others in the list not: If you have a file (let's say readme.txt) in your check out directory, but not under version control (an extra file), and "fossil update" operation brings in a file with the same name, it will report "ADD readme.txt" among the changes, will overwrite your readme.txt file, and mention zero conflicts. It's true that "fossil undo" will restore it, but first you have to notice that it has been totally overwritten before you run any other undoable operation. I made 'fossil update' and 'fossil merge' report a conflict for this operation in [60c6197c8a] and [bb49278a8a]. I also made 'fossil merge' report the number of coflicts. 'fossil update' already did that, but 'fossil merge' not. Change [e1a7a1d9e2]. I also fixed some tests, that don't work anymore in trunk: merge5 and merge_renames. All this code is not in trunk anymore, waiting opinions from other users. Regards, Lluís. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
