Ticket UUID: | 4df5f38f1e564d2970c269bf5ea1d2aec5173dc9 | ||
Title: | Troubles merging a file delete with a file change | ||
Status: | Review | Type: | Feature_Request |
Severity: | Priority: | ||
Subsystem: | Resolution: | Rejected | |
Last Modified: | 2011-08-30 14:22:37 | ||
Version Found In: | 1.18 | ||
Description & Comments: | |||
I have a branch where I have modified a.cpp . If in trunk someone deleted that file, and I run fossil update trunk , fossil will silently merge the branch modifications and the trunk delete silently into a file delete.
Fossil should report this as a conflict. drh added on 2011-08-30 14:22:37 UTC: Even edits in separate files are potentially a conflict, since while both edits might work fine separately, their combination might make the software fail. So, technically, any parallel change to the project is a conflict. But we choose not to make a big deal out of most of these conflicts since most of the time they are benign. The tricky part in a merge algorithm is to identify and announce conflicts that are likely to require programmer intervention and resolution, versus conflicts that the software is probably able to deal with itself. You don't want to announce too many conflicts, because - as with the boy who cried "Wolf!" - users quickly develop conflict-fatigue and end up ignoring real problems. In the case of an edit/delete conflict, the software currently thinks it can deal with that itself. If you want to disagree, then give us some specific cases where that policy causes issues and argue your case. In the absence of a more compelling rationale, I don't think this complaint warrants any changes to the current merge logic. |