Nathaniel Smith spake unto us the following wisdom: > Anyway: Technically we *could* start detecting that conflict you > describe, end-user-wise I could be convinced that we *should* start > detecting that conflict you describe, and also there is some question > to be resolved over how we would report such conflicts to the user > (they have the funny property that there's really not that much that > can be done to resolve them, the file is dead).
So, not to throw a wrench into the mix, here ... but die-die-die has come up quite a few times in Pidgin development, and we've already had to work around it a few times. (Specifically, we cannot fork out several of the libraries in our tree and still propagate changes back to Pidgin, with die-die-die. Ideally we would like to branch im.pidgin.pidgin to im.pidgin.somelib, pivot_root somelib to the root, and drop everything else, then be able to merge changes back and forth across the divide.) Unfortunately, I'm not convinced that content conflicts are always sufficient; for example, suppose I have a function foo() defined in foo.c, which is used in several places in my codebase. I subsequently create a branch, and proceed to eliminate all usage of foo() on the trunk. I notice that it is unused, and drop the file -- with no changes to foo.c. On the branch, I add a few places where foo() is called, and therefore do not drop the file, but do not change it. When I merge, I want to *keep* foo.c, even though it has never changed, due to undetectable (to monotone) semantic-level dependencies. While this example is contrived, it's more or less equivalent to what we would need to break out library branches. Don't let this stop simple progress toward removing die-die-die, though. :-) Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764
signature.asc
Description: Digital signature
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel