Darcs could have some slightly crazy patches like replace-regexp, but to be honest I don’t think that works so well on a large codebase. The problem I’ve had s

Darcs could have some slightly crazy patches like replace-regexp, but to be honest I don’t think that works so well on a large codebase. The problem I’ve had so far thinking about structural patches is that they need to capture several weird kinds of edit that imply that the patch cannot simply mirror the tree structure of the file. Some examples of tree patches (using sexps to show the tree structure): (A B C) -> (A B B2 C) (A B C) -> (let ((b B)) (A b C)) ((A B) (C D)) -> ((A B C D)) ((A B C D)) -> ((A B) X (C D)) (F X (G Y)) -> (G Y) Specifically it is operations like splitting, merging, raising, lowering, and reordering that can cause problems with computational and logical complexity. If you look at the model for pijul, it goes: 1. A file is a totally ordered set of lines (or other atoms), some of which are marked as “deleted” 2. We consider a patch to be a map from one file to another, taking lines that don’t change to their counterparts, deleted lines to “deleted” lines, and changed lines to their new versions. The map must respect the order by being strictly increasing 3. We now generalise to allow for merges (and merge conflicts) by changing total order to partial order (it is a conflict where the ordering is not total) and patches are increasing maps. It is hard to me to see how such a thing would extend to tree-structured files. But other Brooke online seem more confident so maybe I’m wrong.